Discussion :

[Celelibi]

sh n'est plus installé par défaut sur beaucoup de distrib.
Le plus souvent, /bin/sh n'est qu'un lien symbolique vers bash.

[jabbounet]

sh n'est plus installé par défaut sur beaucoup de distrib.
Le plus souvent, /bin/sh n'est qu'un lien symbolique vers bash.

sur une distribution linux ok, sur les unix plus classique c'est souvent des binaires différents..

[Sve@r]

Pourquoi avoir choisi ce shell ?

J'utilise /bin/sh parce que je travaille en environnements hétérogènes (Linux, sun, Unix) et que je veux des scripts 100% compatibles. Et même si /bin/sh n'est qu'un lien symbolique sous Linux vers /bin/bash, je n'utilise que des outils 100% Bourne Shell.

Quels sont les shells que vous avez déjà essayé/utilisé ?

/bin/sh, /bin/ksh, /bin/bash et /bin/rsh pour des commandes à travers le réseau

Quels sont ses avantages/inconvénients ?

Ben les inconvénients du shell est de ne pas pouvoir utiliser les outils puissants bash comme ((...)), les tableaux, toutes les expressions spéciales possibles pour les variables ${var:-....} ou pour test "test -e, test -O, ..."

De plus, j'ai remarqué un truc amusant avec ksh. Prenons une boucle simple de traitement de flux

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
flux |while read ligne
do
    ....
done

rajoutons un petit compteur de ligne

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
cpt=0
flux |while read ligne
do
    cpt=`expr $cpt + 1`
    ....
done
echo $cpt

Malheureusement, le compteur est repassé à 0 en fin de boucle. C'est probablement dû au pipe qui a généré un processus dédié et donc indépendant.

Ben ça, en ksh, ça fonctionne et le compteur a bien la bonne valeur à la fin du done. Et je n'ai jamais compris pourquoi cela fonctionnait en ksh...

Avoir un lien vers le même exe ne veux pas forcément dire que l'exécution sera identique.
si dash/bash à un comportement basé sur le nom de l'exé passé en ligne de commande façon busybox

Exact. J'ai d'ailleurs remarqué que même sous Linux, avec /bin/sh -> /bin/bash, un même script se comportait avec qq minimes différences suivant qu'on le fasse commencer par #!/bin/sh ou #!/bin/bash...

[ok.Idriss]

Bonjour.

Et même si /bin/sh n'est qu'un lien symbolique sous Linux vers /bin/bash

Ceci dépend des distributions. Par exemple, sous Debian, Ubuntu & co, /bin/sh pointe sur /bin/dash il me semble. (Bien que sous Ubuntu, ça n'empêche pas que le shell par défaut soit Bash).

Sous RHEL & co, la il pointe bien vers /bin/bash ...

Cordialement,
Idriss

[Sve@r]

Par exemple, sous Debian, Ubuntu & co, /bin/sh pointe sur /bin/dash il me semble. (Bien que sous Ubuntu, ça n'empêche pas que le shell par défaut soit Bash).

Peut-être sous Debian 6 (pas encore testé) mais sous ma Debian 5 Lenny (installée en 2009), /bin/sh pointait à cette époque encore vers /bin/bash

[ok.Idriss]

Peut-être sous Debian 6 (pas encore testé) mais sous ma Debian 5 Lenny (installée en 2009), /bin/sh pointait à cette époque encore vers /bin/bash

Peut être exclusivement avec Ubuntu & co alors (je viens de vérifier sur une vielle Kubuntu) ...

Sinon je me demande si Ksh ne serait pas une bonne solution de portabilité Unix/Linux, qu'en pensez-vous ? En effet, il est présent dans les dépôts de beaucoup de distros et est le shell par défaut de beaucoup d'Unix (la syntaxe est aussi généralement compatible avec bash d'après ce que j'ai compris).

Cordialement,
Idriss

[Sve@r]

Sinon je me demande si Ksh ne serait pas une bonne solution de portabilité Unix/Linux, qu'en pensez-vous ? En effet, il est présent dans les dépôts de beaucoup de distros et est le shell par défaut de beaucoup d'Unix (la syntaxe est aussi généralement compatible avec bash d'après ce que j'ai compris).

C'est vrai que bash peut se résumer (sans aucune notion péjorative dans ce verbe) à un ksh amélioré mais malheureusement tous les Unix n'ont pas ksh...

[xflr6]

Au risque de déterrer un vieux sujet, mais en apportant un élément à la discussion:
ksh... qui permet de faire de l'arithmétique flottante, qui, pour du calcul scientifique -- sans s'en servir pour de "vrais" calculs bien sûr ! -- peut s'avérer fort utile pour du pré/post processing simple. Je sais qu'au moins sh et bash ne permettent pas ça.

[nanooby]

Dommage qu'on ne puisse en choisir qu'un.

J'ai coché sh, mais je travail également avec des scripts ksh déjà créés.
Je n'ai pas réellement choisi.

[Sve@r]

Dommage qu'on ne puisse en choisir qu'un.

Il s'agissait de donner le shell dans lequel tu travailles "le plus souvent" ou "qui a ta préférence", bref celui que tu choisirais instinctivement si on te donnait un outil (pouvant être écrit dans différents shells) à écrire...

Et les scripts "écrits par d'autres" avec lesquels tu travailles également ne comptent pas (surtout qu'à mon avis, ce "travail" doit se résumer à les exécuter...)

[nanooby]

Il s'agissait de donner le shell dans lequel tu travailles "le plus souvent" ou "qui a ta préférence", bref celui que tu choisirais instinctivement si on te donnait un outil (pouvant être écrit dans différents shells) à écrire...

Et les scripts "écrits par d'autres" avec lesquels tu travailles également ne comptent pas (surtout qu'à mon avis, ce "travail" doit se résumer à les exécuter...)

Non je crée mon propre script pour automatiser le lancement de ces autres scripts, scripts que je dois modifier pour adapter à mon script. C'est-à-dire que certaine tâches sont modifiées, d'autres supprimées, et d'autres ajoutées.

Le script que moi je crée est en Bourne Shell. Je préfère ne pas m'aventurer trop loin dans les autres car je suis novice.

[Sve@r]

Le script que moi je crée est en Bourne Shell. Je préfère ne pas m'aventurer trop loin dans les autres car je suis novice.

ksh et bash sont 100% compatibles Bourne Shell mais avec des outils additionnels. Donc tu peux remplacer #!/bin/sh par #!/bin/bash sans aucun soucis mais t'auras accès à d'autres possibilités (tableaux, calculs, etc...) que tu découvriras au fur et à mesure et qui, au pire, ne changeront rien mais qui, au mieux, amélioreront le rendement de tes scripts...

[nanooby]

ksh et bash sont 100% compatibles Bourne Shell mais avec des outils additionnels. Donc tu peux remplacer #!/bin/sh par #!/bin/bash sans aucun soucis mais t'auras accès à d'autres possibilités (tableaux, calculs, etc...) que tu découvriras au fur et à mesure et qui, au pire, ne changeront rien mais qui, au mieux, amélioreront le rendement de tes scripts...

C'est bon à savoir !

[ok.Idriss]

Le script que moi je crée est en Bourne Shell. Je préfère ne pas m'aventurer trop loin dans les autres car je suis novice.

Roh, il ne faut pas avoir peur (ça vaut le détour, et une fois qu'on est habitué aux possibilités qu'offre Bash on peux difficilement revenir à l'age de pierre )

[jlliagre]

ksh et bash sont 100% compatibles Bourne Shell mais avec des outils additionnels.

s/Bourne/POSIX/

Le Bourne shell est une antiquité présentant quelques incompatibilités et des manques par rapport au shell POSIX. Il n'a été disponible en Open Source qu'en 2006 ( http://heirloom.sourceforge.net/sh.html ) et son utilisation sous Linux est anecdotique.

/bin/sh n'est donc a peu près jamais, sous Linux, le (vrai) Bourne shell mais généralement une implémentation de shell POSIX, le plus souvent fournie par bash ou par dash.

[chavi]

Autrefois avec Unix, c'était plutôt le C-shell (csh).
Maintenant avec Linux, j'utilise en priorité bash.

[disedorgue]

Bonjour,
Pour ceux que ça interessent, on trouve ici, l'une des premières implémentation de sh:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/sh.s

[jlliagre]

ici, l'une des premières implémentation de sh:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/sh.s

Très spartiate, ce shell. Il n'y avait alors que deux builtins, "login" et "cd" ("chdir" à l'époque), les commandes en arrière plan (&), l'expansion des métacaractères (* et ?) traitée par un programme externe et les redirections en entrée et en sortie (< et >).

C'est tout, pas de variables, pas de pipes, pas de structures de contrôle (boucles for, if, case, ...) qui arriveront avec le Bourne shell six ans plus tard.

[disedorgue]

Et oui...
Mais pour l'époque, cela montre la pointure des auteurs (Ken Thompson, Dennis Ritchie) capable de faire quelque chose de fonctionnelle en peu de ligne de code...
Sur le même site, en fouillant un peu, on trouve aussi l'une des premières version du Bourne shell:
http://minnie.tuhs.org/cgi-bin/utree...usr/src/cmd/sh
Et comme on peut le voir, la plupart du source est écrit sous forme de Macro via le preprocesseur C (les define sont dans mac.h)