Je le sais, l'oublie et le réapprends. Il est temps de l'écrire.

Pour exécuter un shscript non exécutable , utilisez:

sh myscript

Pour exécuter un bashscript non exécutable , utilisez:

bash myscript

Pour démarrer un exécutable (qui est n'importe quel fichier avec une autorisation exécutable); vous le spécifiez simplement par son chemin:

/foo/bar
/bin/bar
./bar

Pour rendre un script exécutable, donnez-lui les autorisations nécessaires:

chmod +x bar
./bar

Lorsqu'un fichier est exécutable, le noyau est responsable de trouver comment l'exécuter. Pour les non binaires, cela se fait en regardant la première ligne du fichier. Il doit contenir hashbang:

#! /usr/bin/env bash

Le hashbang indique au noyau quel programme exécuter (dans ce cas, la commande /usr/bin/envest exécutée avec l'argument bash). Ensuite, le script est transmis au programme (en tant que deuxième argument) avec tous les arguments que vous avez donnés au script comme arguments ultérieurs.

Cela signifie que chaque script exécutable doit avoir un hashbang . Si ce n'est pas le cas, vous ne dites pas au noyau de quoi il s'agit , et donc le noyau ne sait pas quel programme utiliser pour l'interpréter. Il pourrait être bash, perl, python, sh, ou autre chose. (En réalité, le noyau utilise souvent le shell par défaut de l'utilisateur pour interpréter le fichier, ce qui est très dangereux car il pourrait ne pas être du tout le bon interprète ou il pourrait être en mesure d'analyser certains d'entre eux mais avec des différences de comportement subtiles telles que le cas entre shet bash).

Une note sur /usr/bin/env

Le plus souvent, vous verrez une frange de hachage comme ceci:

#!/bin/bash

Le résultat est que le noyau exécutera le programme /bin/bashpour interpréter le script. Malheureusement, il bashn'est pas toujours expédié par défaut et n'est pas toujours disponible en /bin. Alors que sur les machines Linux, c'est généralement le cas, il existe une gamme d'autres machines POSIX livrées bashà divers endroits, tels que /usr/xpg/bin/bashou /usr/local/bin/bash.

Pour écrire un script bash portable, nous ne pouvons donc pas compter sur un codage en dur de l'emplacement du bashprogramme. Posix dispose déjà d' un mécanisme pour faire face à ce qui suit: PATH. L'idée est que vous installez vos programmes dans l'un des répertoires qui s'y trouvent PATHet que le système devrait pouvoir trouver votre programme lorsque vous voulez l'exécuter par son nom.

Malheureusement, vous ne pouvez pas simplement faire ceci:

#!bash

Le noyau ne fera pas (pour certains) une PATHrecherche pour vous. Il existe un programme qui peut faire une PATHrecherche pour vous, cependant, il s'appelle env. Heureusement, presque tous les systèmes ont un envprogramme installé dans /usr/bin. Nous commençons donc à envutiliser un chemin codé en dur, qui effectue ensuite une PATHrecherche bashet l'exécute afin qu'il puisse interpréter votre script:

#!/usr/bin/env bash

Cette approche a un inconvénient: selon POSIX, le hashbang peut avoir un argument . Dans ce cas, nous utilisons bashcomme argument du envprogramme. Cela signifie que nous n'avons plus d'espace pour passer des arguments bash. Il n'y a donc aucun moyen de convertir quelque chose comme #!/bin/bash -exuce schéma. Vous devrez set -exuplutôt mettre le hashbang.

Cette approche a également un autre avantage: certains systèmes peuvent être livrés avec un /bin/bash, mais l'utilisateur peut ne pas l'aimer, peut trouver qu'il est bogué ou obsolète, et peut avoir installé le sien bashailleurs. C'est souvent le cas sur OS X (Mac) où Apple expédie une version obsolète /bin/bashet les utilisateurs installent une mise à jour en /usr/local/bin/bashutilisant quelque chose comme Homebrew. Lorsque vous utilisez l' envapproche qui effectue une PATHrecherche, vous tenez compte des préférences de l'utilisateur et utilisez sa commande préférée par rapport à celle fournie avec son système.

Pour démarrer le shell-script 'file.sh':

sh file.sh

bash file.sh

Une autre option est de définir l'autorisation exécutable à l'aide de la commande chmod:

chmod +x file.sh

Exécutez maintenant le fichier .sh comme suit:

./file.sh

Pour la coquille de bourne:

sh myscript.sh

Pour bash:

bash myscript.sh

Si vous voulez que le script s'exécute dans le shell actuel (par exemple, vous voulez qu'il puisse affecter votre répertoire ou votre environnement), vous devez dire:

. /path/to/script.sh

ou

source /path/to/script.sh

Notez que cela /path/to/script.shpeut être relatif, par exemple . bin/script.shexécute le script.shdans le binrépertoire sous le répertoire courant.

Tout d'abord, autorisez l'exécution: -
chmod +x script_name

1. Si le script n'est pas exécutable: -
   Pour exécuter le fichier de script sh: -
   sh script_name
   Pour exécuter le fichier de script bash: -
   bash script_name
2. Si le script est exécutable: -
   ./script_name

REMARQUE : -vous pouvez vérifier si le fichier est exécutable ou non en utilisant 'ls -a'

L'extension de fichier .command est attribuée à Terminal.app. Double-cliquez sur n'importe quel fichier .command pour l'exécuter.

Petit ajout, pour exécuter un interpréteur à partir du même dossier, en utilisant toujours #! Hashbang dans les scripts.

A titre d' exemple un exécutable php7.2 copié à partir de / usr / bin est dans un dossier le long d' un bonjour script.

#!./php7.2
<?php

echo "Hello!"; 

Pour l'exécuter:

./hello

Qui se comportent tout autant que:

./php7.2 hello