Pourquoi exécuter une commande Linux Shell avec '&'?
J'utilise Red Hat Linux Enterprise version 5. J'ai remarqué que des personnes exécutaient parfois des commandes avec quelques options &. Par exemple, dans la commande ci-dessous, il y a deux signes &. Quel est le but d'eux? Sont-ils toujours utilisés avec nohup?
Nohup foo.sh <script parameters> >& <log_file_name> &
En plus des réponses de Martin, Ash et Kevin, vous verrez parfois une esperluette utilisée mathématiquement pour un bit AND*:
$ echo $(( 11 & 7 ))
3
Si vous n'êtes pas familier avec les opérateurs de bits:
11: 1011
7: 0111
-------- AND
3: 0011
Dans chaque position, il y a un bit dans le premier nombre ET le deuxième nombre, définissez ce bit sur un dans la réponse.
*La réponse dans la réponse de Kevin est appelée un logique AND.
Pour préciser la réponse de Ash, l'esperluette peut indiquer au shell, lors d'une redirection, de copier un descripteur de fichier. Dans cette commande echo "hello" > outputfile 2>&1, l'esperluette fait en sorte que toute sortie pouvant aller à l'erreur standard (stderr, descripteur de fichier 2) soit placée au même endroit que la sortie standard (stdout, descripteur de fichier 1, valeur par défaut pour le côté gauche de >). L'opérateur >& outputfile est un raccourci pour > outputfile 2>&1.
De plus, nouveauté dans Bash 4, il existe deux nouveaux terminateurs pour les clauses dans les commandes case, ;& et ;;&, qui déterminent si un cas "échoue" et, le cas échéant, si le test suivant est effectué.
Dans un script Bash Shell, l'esperluette "&" sert à brancher des processus:
find -name hello &
La commande find sera alors lancée et exécutée en arrière-plan (vous pouvez toujours la tuer par son PID).
Pourquoi exécuter une commande Linux Shell avec '&'?
Pour récupérer votre invite immédiatement et exécuter le processus en arrière-plan.
Quelles sont leurs fonctions?
Nohup permet au processus d'arrière-plan de continuer à s'exécuter même après la déconnexion de l'utilisateur (ou la fermeture du shell initiateur).
> & redirige à la fois la sortie standard et l'erreur standard dans le fichier journal.
& exécute le tout en arrière-plan, vous rendant immédiatement votre invite.
Explication:
Chaque processus Linux ouvre trois canaux d'E/S, une entrée "stdin", une sortie standard "stdout" et une sortie d'erreur standard "stderr". Ils peuvent être utilisés pour le binaire, mais ils sont traditionnellement du texte. Lorsque la plupart des programmes voient stdin fermer, ils se ferment (cela peut être modifié par le programmeur).
Lorsque le parent Shell quitte, stdin est fermé pour les enfants et (souvent, généralement), les enfants quittent également. De plus, les enfants reçoivent un signal logiciel, SIGHUP, indiquant que l'utilisateur a "raccroché" (anciennement, le modem) et que la valeur par défaut est également de sortir. (Remarque, un programmeur peut changer tout cela lors de l'écriture du programme).
Donc, Nohup donne au processus enfant un environnement d’E/S distinct, liant les tenants et les aboutissants à quelque chose qui n’est pas lié au shell parent et protégeant l’enfant du signal SIGHUP. Une fois que l'utilisateur s'est déconnecté, vous verrez que le processus d'arrière-plan Nohup appartient à init (processus 1) et non au shell de l'utilisateur.
Cependant, Nohup ne peut pas exécuter le travail complètement si le processus est exécuté au premier plan. & est donc utilisé pour exécuter le programme en arrière-plan, où il peut continuer à fonctionner avec ou sans utilisateur connecté.
En plus de la réponse de @ Martin: L'autre utilisation de l'esperluette (>& comme ci-dessus) consiste à capturer à la fois stdout et stderr. Normalement, si vous redirigiez la sortie vers un fichier contenant uniquement '>', vous n'obtiendrez que la sortie à stdout, sans erreur.
En plus de la réponse de Martin et Ash, vous pouvez parfois voir l'utilisation d'un jeton &&. Ceci est utilisé pour dire "exécutez la deuxième commande si et seulement si la première commande a été exécutée avec succès". Une commande bien écrite, si elle contient des erreurs, ne se ferme pas correctement.
[kevin@box ~]$ ls file && echo removing file && rm file
ls: file: No such file or directory
[kevin@box ~]$ touch file
[kevin@box ~]$ ls file && echo removing file && rm file
file
removing file
[kevin@box ~]$
La réponse de Martin est bonne, mais un peu ambiguë. La commande est toujours forkée et exécutée, mais le comportement normal du shell consiste à attendre que la commande se termine. L'esperluette le met en arrière-plan pour que vous obteniez votre invite de terminal et que vous puissiez faire autre chose. Si le processus génère des données sur stdout ou stderr, celles-ci seront mélangées à ce que vous êtes en train de faire à l'invite et risquent de vous semer la confusion. C'est pourquoi vous redirigez ensuite avec> & /path/to/logfile.txt.
En réponse à George2, le comportement normal d'un Shell sortant consiste à envoyer le signal SIGHUP à tous les processus du même groupe de processus (essentiellement les éléments que vous avez créés) et ils se termineront généralement. Si vous souhaitez que cela continue même si vous fermez le processus Shell, vous pouvez utiliser la commande Nohup pour leur faire ignorer ce signal et continuer à s'exécuter. Il existe un nom spécial pour ce type de processus, il s'agit d'un processus démon (prononcé "démon").