Vous pouvez toujours utiliser un lien symbolique car /bin/sh, dans la plupart des cas sur linux, c'est déjà un lien symbolique vers bash. C'est juste que beaucoup de scripts utilisent du /bin/sh
code
5
Maintenant que vous avez la réponse qu'il peut vivre où il veut, vous pouvez vous demander: comment pouvez-vous alors écrire de manière portable une ligne de shebang sh? Et la réponse est: shebang ne fait pas non plus partie de POSIX, donc le problème ne se pose même pas.
Jörg W Mittag
1
@ JörgWMittag Oui, il est parfois surprenant de voir combien de choses que nous considérons comme des fonctionnalités Unix "standard" ne sont pas réellement requises par POSIX.
Barmar
1
Que vous utilisiez ou non un shebang est indépendant du fait que le chemin /bin/shdoit exister sur un système POSIX.
chepner
Au moins sur les systèmes dérivés d'Ubuntu, /bin/shest un lien vers dash. Sur les BSD, ce /bin/shn'est pas un lien mais un exécutable séparé, et certainement pas bash.
Rhialto soutient Monica le
Réponses:
22
Seuls les mandats Posix /devet /tmprépertoires Exister , et les /dev/null, /dev/ttyet les /dev/consolefichiers. Les utilitaires standard doivent exister, mais aucun emplacement particulier n'est spécifié. Il peut ne pas y en avoir /bindu tout, et s'il y en a, il peut ne pas contenir de a sh, et si c'est le cas, il peut ne pas s'agir d'un POSIX sh.
Vous pouvez obtenir une PATHvariable valide qui inclut les outils POSIX, notamment shavec la getconfcommande :
Concernant Solaris: ... sauf si vous exécutez une installation "petit serveur" Solaris, qui omet de nombreux outils POSIX. Voir unix.stackexchange.com/q/360359/135943
Wildcard
"Inutiles"? Je préfère les appeler redondants.
Mukesh Sai Kumar
2
alors comment trouve-t-on getconf?
Joshua
@MukeshSaiKumar une commande autonome 'cd' ne peut jamais fonctionner
OrangeDog
Eh bien, cela "fonctionnera" uniquement pour une valeur de travail qui, disons, teste si vous pouvez passer à un répertoire, mais ne laisse pas réellement le processus qui l'a appelé là. C'est plus de fonctionnalités que pas du tout, cependant.
Charles Duffy
12
Non, il n'est pas nécessaire shd'être présent /bin. Il cite explicitement /bin, /usr/binet /usr/xpg4/binque les emplacements possibles. La spécification POSIX ne nécessite que d' shêtre dans le CHEMIN.
Les applications doivent noter que le PATH standard vers le shell ne peut pas être supposé être /bin/shou /usr/bin/sh, et doit être déterminé par interrogation du PATH retourné par getconf PATH, garantissant que le chemin retourné est un chemin absolu et non un shell intégré.
Par exemple, pour déterminer l'emplacement de l'utilitaire sh standard:
command -v sh
Sur certaines implémentations, cela pourrait revenir:
Comme d'autres l'ont dit ici, cela n'est pas strictement requis pour la conformité POSIX.
Mais la compatibilité avec les logiciels existants est sans doute beaucoup plus importante (après tout, le but de POSIX est de faire fonctionner certaines choses sur tous les systèmes d'exploitation conformes) et si un système d'exploitation ne fournit pas sh at /bin/sh , cela cassera certaines choses.
Une autre façon dont certaines implémentations historiques gèrent les scripts shell est de reconnaître les deux premiers octets du fichier comme la chaîne de caractères "#!" et utiliser le reste de la première ligne du fichier comme nom de l'interpréteur de commandes à exécuter.
Mais si cela n'est pas pris en charge, de nombreux logiciels existants se briseront ou nécessiteront un travail supplémentaire pour le portage.
/bin/sh, dans la plupart des cas sur linux, c'est déjà un lien symbolique versbash. C'est juste que beaucoup de scripts utilisent du/bin/shsh? Et la réponse est: shebang ne fait pas non plus partie de POSIX, donc le problème ne se pose même pas./bin/shdoit exister sur un système POSIX./bin/shest un lien versdash. Sur les BSD, ce/bin/shn'est pas un lien mais un exécutable séparé, et certainement pasbash.Réponses:
Seuls les mandats Posix
/devet/tmprépertoires Exister , et les/dev/null,/dev/ttyet les/dev/consolefichiers. Les utilitaires standard doivent exister, mais aucun emplacement particulier n'est spécifié. Il peut ne pas y en avoir/bindu tout, et s'il y en a, il peut ne pas contenir de ash, et si c'est le cas, il peut ne pas s'agir d'un POSIXsh.Vous pouvez obtenir une
PATHvariable valide qui inclut les outils POSIX, notammentshavec lagetconfcommande :Cela peut être utile, par exemple, sur Solaris, où la valeur par défaut
shn'est pas compatible POSIX , mais un conformeshest fourni et accessible de cette manière (car Solaris est un Unix certifié ).getconf PATHcomprendra/usr/xpg4/binà l'avant, qui contient POSIXshet un certain nombre d'autres outils requis ( y compris ceux inutiles commecd).la source
Non, il n'est pas nécessaire
shd'être présent/bin. Il cite explicitement/bin,/usr/binet/usr/xpg4/binque les emplacements possibles. La spécification POSIX ne nécessite que d'shêtre dans le CHEMIN.La spécification POSIX indique:
la source
Comme d'autres l'ont dit ici, cela n'est pas strictement requis pour la conformité POSIX.
Mais la compatibilité avec les logiciels existants est sans doute beaucoup plus importante (après tout, le but de POSIX est de faire fonctionner certaines choses sur tous les systèmes d'exploitation conformes) et si un système d'exploitation ne fournit pas sh at
/bin/sh, cela cassera certaines choses.De toute évidence, les scripts
#!/bin/shreposent sur la normalisation de ce chemin. Ce n'est pas obligatoire pour travailler; POSIX n'exige même pas que les#!lignes soient prises en charge, bien qu'il mentionne qu'une telle fonctionnalité est courante :Mais si cela n'est pas pris en charge, de nombreux logiciels existants se briseront ou nécessiteront un travail supplémentaire pour le portage.
la source