"Sh" doit-il être dans le répertoire "/ bin"?

J'ai lu que les systèmes d'exploitation compatibles POSIX (par exemple: Linux) doivent avoir le shshell.

Mais est-il nécessaire pour shêtre dans le /binrépertoire, ou peut-il être dans n'importe quel répertoire?

linux shell posix

— user270294
source

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

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

@ 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

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:

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 :

$ PATH=$(getconf PATH)
$ sh

Cela peut être utile, par exemple, sur Solaris, où la valeur par défaut shn'est pas compatible POSIX , mais un conforme shest fourni et accessible de cette manière (car Solaris est un Unix certifié ). getconf PATHcomprendra /usr/xpg4/binà l'avant, qui contient POSIX shet un certain nombre d'autres outils requis ( y compris ceux inutiles commecd ).

— Michael Homer
source

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

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

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:

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:

/usr/xpg4/bin/sh

— John1024
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 :

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.

— Ian D. Scott
source