Quel est l'objectif de la sh lorsqu'elle est utilisée de manière interactive et lorsqu'elle est utilisée à l'intérieur d'un script bash ?
A part sur la ligne du hash bang (la première ligne), il faut sh jamais être remplacé par bash sur un système bash ?
Exemple :
#!/bin/bash
sh -c "command"Tant de questions... Je vais les prendre une par une.
1) Quel est le but de la commande sh lorsqu'elle est utilisée de manière interactive ? Fournir un nouveau contexte d'environnement, donc si vous voulez expérimenter avec un paramètre de variable d'environnement, vous pouvez le faire. Et quand vous aviez fini, exit et aucun mal n'a été fait.
Aussi, si vous étiez dans un Shell différent comme zsh ou csh, et que vous vouliez exécuter dans un sh Shell, ça te changerait.
2) Lorsqu'il est utilisé dans un bash script comme vous l'avez ci-dessus, il fournira à nouveau un contexte d'environnement contenu pour l'exécution de "command". Vous pouvez également l'utiliser avec l'option
#!/bin/bash
sh -c "command" &et bifurquez sur "command" pour l'exécuter en parallèle avec le reste de votre script.
3) Je dirais que, si c'est quelque chose qui a besoin spécifiquement bash alors mettez-le explicitement dans votre ligne de hash bang. Mais comme sur la plupart des systèmes *nix ultérieurs sh est équivalent à bash il n'est probablement pas nécessaire de le faire.
sh ?Si vous commencez simplement sh sur le Shell, vous allez commencer un autre Shell à l'intérieur de votre Shell actuel .
sh dans un script ?La même chose, vous démarrez un autre Shell à l'intérieur du Shell qui traite le Shell.
/bin/bash si c'est ce que /bin/sh de toute façon ?Non . Si le script a été conçu pour fonctionner avec cualquier Shell, alors il est conçu pour fonctionner contre le plus petit dénominateur commun entre tous les shells (à ma connaissance, cela fait partie de l' Norme POSIX ).
Passer à un spécifique ne devrait pas être nuisible (parce qu'ils sont tous conformes à la même norme) mais il réduit la compatibilité tout en n'apportant aucun avantage.
/bin/sh alors ?Non. Si vous écrivez un script vous-même vous pouvez également utiliser un interpréteur plus spécifique (comme bash) si cet interpréteur fournit des fonctionnalités supplémentaires que vous souhaitez utiliser. Mais gardez à l'esprit que tous ceux qui utilisent votre script devront avoir l'interpréteur que vous avez choisi.
Si vous voulez simplement démarrer un nouveau processus dans son propre contexte, alors, par tous les moyens, utilisez /bin/sh .
Si vous voulez exécuter quelque chose dans son propre contexte vous devez l'exécuter dans un nouveau Shell.
Le moyen le plus simple d'y parvenir est de lancer un nouveau Shell (à l'aide du bouton sh ) et lui transmettre la commande.
Tant que votre quelque chose n'est pas un script spécifiquement conçu pour un script spécifique, il n'y a aucune raison d'invoquer un script spécifique. Il suffit d'invoquer cualquier Shell, en utilisant sh .
Si vous disposez d'un script, qui utilise une syntaxe spéciale uniquement disponible dans l'application bash vous devez alors définir l'option shebang en conséquence.
sh n'est pas une commande Shell mais un programme que vous appelez. Votre ligne cherchera sh sur votre chemin. Dans la plupart des cas, il suffit d'exécuter /bin/sh qui se trouve dans le chemin.
Cela lancera un nouveau processus.
/bin/sh n'est pas garanti d'être bash, c'est maintenant sur de nombreux systèmes bash mais sur plusieurs systèmes Unix c'est le Bourne Shell. Si vous exécutez /bin/sh vous pouvez simplement vous attendre à un Shell adhérant à la norme POSIX.
Pourquoi /bin/sh ?
Comme d'autres l'ont souligné, c'est à vous de décider ce que cela signifie réellement :) (Ou votre distro le fait pour vous).
Pour bash au moins, il a une signification particulière...
Depuis la page de manuel de bash :
" Si bash est invoqué avec le nom sh, il essaie d'imiter au mieux le comportement au démarrage des versions historiques de sh, tandis que possible, tout en se conformant également à la norme POSIX. "
Ainsi, si votre /bin/sh pointe vers /bin/bash, vous obtenez ce comportement.
!/bin/bash
vous donne un bash "standard". (et ses "bashismes")
Bien sûr, /bin/sh peut en fait être un lien vers /bin/dash ou ksh ou tout autre "Shell".
La page de manuel de bash est énorme mais cette information particulière ne fait que... 145 lignes :)
Il y a quelques bonnes introductions : Le Guide avancé des scripts Bash est excellent.
Si vous êtes sous Debian / Ubuntu (ou autres dérivés) :
abs-guide - Le guide avancé des scripts Bash
debian-reference-fr -> Guide d'administration du système Debian, original anglais
par exemple
apt-get install abs-guideFYI dash : (édité jusqu'à la description)
$ apt-cache show dash
dit :
Description-en : Shell conforme à POSIX Le Shell de Debian Almquist
(tiret) est un Shell conforme à POSIX, dérivé de ash .
Puisqu'il exécute les scripts plus rapidement que bash,
et a moins de dépendances de bibliothèque
(ce qui le rend plus robuste contre les défaillances logicielles ou matérielles),
il est utilisé comme système par défaut Shell sur les systèmes Debian.
Page d'accueil :
1) C'est un Shell. Son but en mode interactif est de lire les entrées de l'utilisateur et d'exécuter les commandes spécifiées. En mode non interactif, il lit toutes les commandes du fichier Shell, il fonctionne donc sans que l'utilisateur ne touche jamais le clavier.
2) La différence entre "sh -c command" et juste "command" dans le fichier script est que dans le premier cas, la commande est bifurquée d'un processus script distinct, alors que dans le second cas, elle est bifurquée du processus exécutant le script script principal (c'est-à-dire qu'il a accès à ses descripteurs de fichiers, à son environnement, etc.) Nous avons donc un processus supplémentaire dans l'arbre des processus dans le premier cas, et aussi un certain degré d'isolation.
3) /bin/sh peut être un lien symbolique vers /bin/zsh (par exemple), donc, oui, si vous voulez lancer bash enfant script à partir de bash principal script, vous devez dire explicitement "bash -c". Si le script enfant est script-indépendant, alors "sh -c" fera aussi bien l'affaire.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
