|
Cette même question peut se poser lors de l'utilisation de n'importe quel type de script, pas seulement les scripts bash. Existe-t-il une différence majeure entre exécuter un script via l'interpréteur et l'exécuter directement?
Un autre mystère que nous allons révéler dans cet article intéressant de Let's Use Linux (uL). |
Lorsque vous exécutez un script en passant le nom de fichier du script à un interpréteur (sh, python, perl, etc.), vous exécutez en fait l'interpréteur, en passant le programme que vous voulez exécuter en argument. Par exemple, nous exécutons l'interpréteur sh en lui passant l'argument miscript.sh.
sh misscript.sh
Si vous exécutez le script par lui-même, le système appellera l'interpréteur dont il a besoin et, ensuite, oui, il exécutera le script en le passant comme argument à l'interpréteur, mais le tout automatiquement et sans que l'utilisateur qui a exécuté le script le sache il.
./misscript.sh
Pour exécuter un script seul, 2 conditions doivent être remplies:
1) le script doit inclure une "ligne de coup". C'est la première ligne d'un script, qui doit commencer par les caractères #! et que vous devez spécifier le chemin où se trouve l'interpréteur. Il est important de noter que cette condition est vraie pour tout type de script (python, perl, etc.), pas seulement ceux de bash.
Ainsi, par exemple, notre script doit contenir ce qui suit comme première ligne:
#! / Bin / bash
2) le fichier doit avoir des autorisations d'exécution:
Pour accorder des autorisations d'exécution à notre script, nous devons écrire:
chmod a + x miscript.sh
Prêt, maintenant lancez-le comme ceci:
./misscript.sh
Ou en copiant le script dans un chemin "spécial" qui lui permet d'être appelé facilement. Par exemple, nous pouvons le copier dans / usr / sbin et l'exécuter de n'importe où sans inclure le chemin complet où il se trouve:
Nous copions:
sudo cp miscript.sh / usr / sbin / miscript
Nous exécutons:
mal écrit
Comme vous pouvez le voir, en réalité, ce qui se passe dans les coulisses est très similaire dans les deux cas. Cependant, en incluant une "bang line", vos scripts seront beaucoup plus faciles à distribuer, puisque les utilisateurs n'auront pas à se souvenir du chemin où se trouvent les interprètes nécessaires pour pouvoir les exécuter. Conclusion: c'est essentiellement une question de confort.
Je suis d'accord avec vous Erpower, tant la version de l'interpréteur que son chemin sont variables et non constants, d'autant plus si l'on considère que les distributions GNU / Linux ne sont pas les seules à utiliser Bash (il y a aussi: freeBSD, OpenSolaris , Mac) et beaucoup d'entre eux ont des configurations ou des itinéraires différents.
L'important est de savoir que vous avez la souplesse (comme vous l'avez bien mentionné) pour jouer avec l'appel au script, soit avec ./, soit avec sh (ou python ... etc)
Bash est un programme informatique dont la fonction est d'interpréter les commandes.
Il est basé sur le shell Unix et est compatible POSIX.
au lieu de cela, sh est un programme informatique dont la fonction est d'interpréter les commandes.
Intègre des fonctionnalités telles que le contrôle de processus, la redirection
entrée / sortie, listage et lecture de fichiers, protection,
communications et un langage de commande pour écrire des programmes par
lots ou scripts. C'était l'interpréteur utilisé dans les premières versions d'Unix et il est devenu un standard de facto.
Bonjour, je suis un débutant dans l'utilisation de scripts et j'aimerais savoir si quelqu'un peut m'aider avec un problème que j'ai:
Je gère un programme qui nécessite l'inclusion de plusieurs données initiales via la console et j'ai découvert que grâce à un script, il est possible d'exécuter le programme avec les données initiales, afin de ne pas avoir à l'écrire encore et encore quand je besoin d'exécuter le programme.
Je ne sais pas comment faire, donc si quelqu'un peut m'aider avec cela, je serai très reconnaissant.
Vous voyez, cela dépend du langage de programmation dans lequel vous écrivez le script. Cependant, dans tous les cas, ce dont vous avez besoin est:
1) Si vous souhaitez que l'utilisateur doive saisir ces données chaque fois que le script est exécuté, la procédure la plus courante consiste à ce qu'une variable prenne les valeurs saisies dans l'entrée.
2) Dans le cas où les valeurs sont toujours les mêmes, vous pouvez utiliser des constantes.
3) Une autre option est la possibilité que votre script puisse prendre des paramètres.
À votre santé! Paul.
C'est intéressant ce que vous mentionnez. Il est appelé de deux manières: ligne de shebang ou ligne de coup direct. Je vous donne les informations: http://python.about.com/od/programmingglossary/g/defbangline.htm
À votre santé! Paul.
Intéressant, je n'avais jamais cessé de penser à ce détail. Il serait intéressant de voir des articles de bricolage plus consolateurs, parmi lesquels la fameuse recompilation du noyau pour supprimer les kilos de code inutile qui ne sont là que pour la compatibilité et améliorer la vitesse du système.
D'ACCORD. Je garderai ça à l'esprit.
À votre santé! Paul.
Je suis content que cela ait fonctionné. J'essaie toujours de publier des choses qui, à mon avis, pourraient être intéressantes et pratiques.
Un câlin! Paul.
Chaque programmeur avec de bonnes habitudes ajoute une «ligne de coup» à la première ligne de code. En Python, je n'oublie jamais le codage et la ligne de coup.
#! / usr / bin / python2.7
# *. * encodage = utf-8 *. *
Excellent, j'espère que vous pourrez publier plus d'informations sur la ligne de commande, en particulier lorsqu'il s'agit de compiler ou d'installer à partir de fichiers source (tar.gz, etc.)
Je n'avais jamais entendu parler de «bang line», je l'ai toujours connu sous le nom de Shebang
http://en.wikipedia.org/wiki/Shebang_%28Unix%29
salutations
note intéressante… merci!
Comme c'est intéressant, je me déclare totalement ignorant de la programmation et de tout ce qui touche au script, je n'avais aucune idée de comment cela fonctionne, mais j'ai remarqué que certains ont cet en-tête.
Une précision qui m'est arrivée à propos de cette entrée: je voulais installer un gadget Adobe Air (un calculateur de cotes de poker). Le programme d'installation d'Adobe Air exécute le script correspondant avec "su" mais sous la forme ./ vous demandant le mot de passe root. Comme le script n'avait pas les autorisations d'exécution, il a rejeté l'autorisation, la solution: exécutez le script avec sh si vous ne voulez pas changer les autorisations (plus rapidement que d'aller dans le dossier tmp chmod et tout ça). Là, le script est exécuté, il appelle le programme d'installation d'adobe et quelque chose d'autre papillon.
Article très intéressant! Merci de m'aider à en savoir un peu plus sur la console. Voyons si vous continuez à publier des articles comme ceux-ci ^^.
Continuez comme ça, c'est sans aucun doute mon blog préféré !!
Gardez à l'esprit qu'il peut y avoir des différences entre les versions de l'interpréteur utilisées. Exécuter le script directement en fonction du shebang, il n'y a aucun moyen d'indiquer quelle version de l'interpréteur utiliser, ce qui peut être nécessaire. Si vous exécutez l'interpréteur à la place et transmettez le script en tant que paramètre, vous savez quelle version de celui-ci est en cours d'exécution.
Par exemple en Python, si le shebang est #! / Usr / bin / python2.4 le programme fonctionnera différemment que s'il est #! / Usr / bin / python2.6 ou s'il est #! / Usr / bin / python (qui est généralement un lien symbolique vers la version de Python installée et configurée par défaut). Cela se produit parce que Python 2.6 a une nouvelle fonctionnalité qui n'existait pas dans Python 2.4, donc l'écriture d'un script qui utilise cette fonctionnalité indiquant un shebang #! / Usr / bin / python échouera si le système n'a installé que python 2.4. Au lieu de cela, vous pouvez toujours forcer le script à s'exécuter avec la version de python que vous souhaitez en le démarrant avec "python2.4 /path/al/script.py" ou "python2.6 /path/al/script.py/
Pour les scripts shell, il existe également des différences entre les shells que vous utilisez, donc l'utilisation de #! / Bin / sh et #! / Bin / bash peut avoir des résultats différents selon le script. Si vous écrivez un script utilisant des fonctionnalités qui n'existent que dans bash mais indiquez un shebang #! / Bin / sh, votre script fonctionnera probablement sous Linux (sur la plupart des distributions / bin / sh est un lien symbolique vers bash) mais il échouera probablement dans d'autres UNIX où bash n'est pas installé ou où / bin / sh n'est pas un lien symbolique vers / bin / bash.
Également lié à la portabilité, il faut tenir compte du fait que le chemin indiqué dans le shebang est absolu, et qu'il y a des moments où les interprètes sont installés à d'autres endroits. Par exemple, il est courant d'avoir l'interpréteur python installé dans / usr / local / bin / python si vous avez téléchargé et compilé Python au lieu d'utiliser un package de votre distribution. Si votre shebang est #! / Usr / bin / python, le script ne fonctionnera pas sur ces systèmes. Pour essayer d'éviter ces problèmes, vous pouvez utiliser comme shebang "#! / Usr / bin / env python" (ou "#! / Usr / bin / env sh") comme expliqué dans http://en.wikipedia.org/wiki/Shebang_(Unix)#Portability
Merci Jonathan! Ravi de vous voir commenter!
À votre santé! Paul.
Nulle part ce que je veux savoir, ou du moins je ne sais pas comment le relever dans le moteur de recherche, je veux créer un script qui pour une raison xX exécute la commande aptitude ou «su» (ce n'est qu'un exemple mais ce sont les 2 cas auxquels je peux penser) et dans le cas d'aptitude il me demande parfois d'entrer "yon" ou dans le "su" il me demande le mot de passe ... j'aimerais que le script sélectionne ces options automatiquement soit en passant un paramètre, soit en utilisant une méthode qu'il ne connaît pas .... Merci pour l'attention
Bonjour Antonio! Si votre problème est d'avoir à saisir le mot de passe, je ne pense pas qu'il existe une solution. Précisément parce que c'est une mesure de sécurité, de sorte que tout le monde ne peut pas installer un programme.
En ce qui concerne l'aptitude et devoir mettre oui, je pense que cela peut être résolu. Je ne me souviens pas pour le moment du paramètre exact à utiliser, mais renseignez-vous simplement dans les pages de manuel. Ouvrez un terminal et entrez la commande: man aptitude.
Étreinte! Paul.
Très bon message.
J'ai particulièrement aimé -dans ce post- que la question / le doute qui se pose soit répondu de manière très claire et concise.