Bonjour à tous,
voilà, j’ai créé un petit firewall pour la maison et je voulais évidemment qu’il s’active à cjaque démmarge de la machine.
cela ne m’a posé aucun problème proprement dit, toutefois j’ai du rajouter une ligne, la première (lol), pour permettre son exécution au démarrage.
il s’agit de ceci : #!/bin/bash
j’ai constaté qu’il existait certains scripts qui débutaient par : #!/bin/sh
quel signifie cette différence de syntaxe…?
Merci d’avance 
Merci 
mais que se passerait-il si je remplaçait par #!/bin/sh ?
quelle est l’utilité de celui-ci sur une sarge?
slt,
2 choses, Debian (sarge, etch, …) c’est la distrib ok, ensuite bash c’est interpreteur de commande il n’y a aucun rapprochement.
bon, j’insiste pas…
merci quand même
(ps: je sais ce qu’est une distrib, merci quand même )
l’instruction #! permet de preciser l’interpreteur (de commandes) qui va prendre comme entrée standard le suite du script. Ce n’est pas necessairement un script shell, ça peut être du perl, du php, ou du python, ou une appli perso. En fait, le lancement de n’importe quel script commence par lancer un shell, qui est ensuite “remplacé” par l’interpreteur désigné par #!
Il se trouve que maintenant, /bin/bash, si je me souviens bien, ainsi peut être que bash2 sont des liens vers un même executable (bash2).
Cela veut dire que #!/bin/bashest équivalent à #!/bin/sh
[quote=“Karlinux”]Merci
mais que se passerait-il si je remplaçait par #!/bin/sh ?
quelle est l’utilité de celui-ci sur une sarge?[/quote]
Il ne se passerait pas grand chose:
jeannot@burp:~$ which bash
/bin/bash
jeannot@burp:~$ which sh
/bin/sh
jeannot@burp:~$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 2005-12-20 16:38 /bin/sh -> bash
jeannot@burp:~$
Eh oui, sous linux, comme tu peux le voir, sh est redirigé sur bash ! 
En fait, historiquement, sh si je ne me trompe, a probablement été le premier shell disponible sous unix. Sur les gros systèmes unix professionnels, c’est d’ailleurs par défaut le premier shell disponible dans les 1ères phases de démarrage de la machine.
Si tu regardes le répertoire /etc/init.d d’une machine linux, tu verras que beaucoup de scripts de démarrage appellent /bin/sh.
burp:/etc/init.d# head -1 * | grep /bin/sh | wc -l
62
burp:/etc/init.d# head -1 * | grep /bin/bash | wc -l
4
burp:/etc/init.d#Ce qui nous fait 62 scripts faisant appel à sh et seulement 4 appelant bash !
Ce qui sur Debian/linux n’a pas d’importance étant donné que c’est redirigé sur bash.
Par contre, ca permettrait à ces scripts d’être compatibles avec différents systèmes, unix qui n’auraient pas forcément bash installé en standard. Par défaut, sur beaucoup d’Unix, c’est d’abord sh qui est appelé, et s’il n’est pas trouvé c’est ensuite bash.
Bref, tu peux utiliser sh ou bash indifférement …
Le bash est en quelque sorte une version améliorée de l’antique shell sh. Si tu regardes la man page de bash, tu peux voir qu’il dispose d’un langage de programmation très évolué.
En fait je crois que /bin/sh est un lien vers le shell par défaut du système. Ce shell peut être /bin/csh ou /bin/zsh par exemple. Ces shells ne sont pas complètement compatibles avec /bin/bash. Si ton script marche avec bash et que tu n’est pas sûr n’est dans les normes du shell unix standard, alors met /bin/bash, si ton script est parfaitement orthodoxe, alors il fonctionne à priori avec n’imprte quel shell et tu peux mettre /bin/sh. L’avantage est que bash peut ne pas être installé (exemple linux embarqué avec ash, Unix non linux, etc). (Par défaut met /bin/sh)
[quote=“fran.b”]En fait je crois que /bin/sh est un lien vers le shell par défaut du système. Ce shell peut être /bin/csh ou /bin/zsh par exemple. Ces shells ne sont pas complètement compatibles avec /bin/bash. Si ton script marche avec bash et que tu n’est pas sûr n’est dans les normes du shell unix standard, alors met /bin/bash, si ton script est parfaitement orthodoxe, alors il fonctionne à priori avec n’imprte quel shell et tu peux mettre /bin/sh. L’avantage est que bash peut ne pas être installé (exemple linux embarqué avec ash, Unix non linux, etc). (Par défaut met /bin/sh)[/quote]disons que la norme, c’est ce qu’on attend de sh, et que tous les autres respectent la norme.
Mon interrogation etait juste de savoir si les fonctionnalités de bash étaient limitées à celles de sh au cas ou on l’appelle sous le nom sh.
hello all,
Extrait de la documentation sur gnu.mirror.fr/software/bash/manu … .html#SEC1 :
[quote]
Bash is the shell, or command language interpreter, for the GNU operating system. The name is an acronym for the `Bourne-Again SHell’, a pun on Stephen Bourne, the author of the direct ancestor of the current Unix shell /bin/sh, which appeared in the Seventh Edition Bell Labs Research version of Unix.
Bash is largely compatible with sh and incorporates useful features from the Korn shell ksh and the C shell csh. It is intended to be a conformant implementation of the IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2). It offers functional improvements over sh for both interactive and programming use[/quote]
Comme le dit jabba :
Et MattOTop :
Voilà, maintenant ici on connait la différence en bash et sh.
Merci pour vos renseignements
@+
Si bash est invoqué sous le nom sh, il essaye d'imiter le comportement de démarrage des versions
historiques de sh autant que possible, tout en restant conforme au standard Posix. Lorsqu'il est
invoqué comme shell de login interactif (ou non-interactif avec l'option --login), il essaye
d'abord d'exécuter les commandes se trouvant dans /etc/profile et ~/.profile, dans cet ordre.
L'option -noprofile peut toujours être utilisée pour désactiver ce comportement. Quand il est
invoqué en tant que shell interactif sous le nom sh, bash consulte la variable ENV, développe sa
valeur si elle est définie et utilise le résultat en tant que nom de fichier à lire et exécuter.
Comme un shell invoqué sous le nom sh n'essaye pas d'exécuter d'autre fichier de démarrage,
l'option --rcfile n'a aucun effet. Un shell non interactif invoqué sous le nom sh ne lit aucun
autre fichier d'initialisation. Quand il est invoqué sous le nom sh, bash entre en mode posix
après avoir lu les fichiers d'initialisation.
Selon moi, d’une si tu mets /bin/bash tu es s^ur de lancer bash (avec toutes les extensions exemple celles non POSIX mais tres pratiques) et non pas dash par exemple (qui est posix compliant et tres rapide), de deux si tu lance /bin/sh certains fichier de conf ne sont pas executés (.bashrc,…).
Perso je mets toujours /bin/sh parceque je n’ai pas besoin de parser les .bashrc et consors.
Bon je rouvre la discussion suite à une remarque de MattOTop.
En fait c’est plus sournois que ca:
Prenons cette ligne non posix:
depfile=${1:Patate}Mon shell par defaut (dans passwd) est /bin/bash. Mon /bin/sh est linké sur bash
Je crée le script en mettant le shebang et la ligne precedente
#!/bin/bash
depfile=${1:Patate}Ca marche, normal.
Je remplace le shebang par /bin/sh donc ca ne devrait pas marcher.
Bing, ca marche .
Je remplace par /bin/dash, ca marche toujours.
En fait ca dépend du shell par lequel on l’appele:
#dash
#./script
Syntax error, Bad susbtitution
je remets /bin/bash pour le shebang, toujours à partir de dash
#./script
<ca marche>
Bash se fout du shebang en fait
quote="BorisTheButcher"Bash se fout du shebang en fait[/quote]Pas cool…
je ne connaissais pas le terme shebang, tu le tiens d’où ?
C’est quand je faisais du perl on m’avait sorti ca j’avais été étonné aussi
Idem j’ai entendu parler du shebang en faisant du perl.
[quote]If Bash is your default shell, then the #! isn’t necessary at the beginning of a script. However, if launching a script from a different shell, such as tcsh, then you will need the #!.
tldp.org/LDP/abs/html/sha-ba … FTN.AEN209
[/quote]
J’aime la citation de la page du lien:
Shell programming is a 1950s juke box . . .
Larry Wall