Pourquoi exécuter une commande shell Linux 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 leur but? 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 ET binaire ^* :

$ 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, mettez ce bit à un dans la réponse.

^{* _{La fonctionnalité de la réponse de Kevin est appelée un ET logique .}}

Pour développer la réponse d'Ash, lorsqu'elle est utilisée dans la redirection, l'esperluette peut dire au shell de copier un descripteur de fichier. Dans cette commande, echo "hello" > outputfile 2>&1l'esperluette fait que toute sortie pouvant aller à l'erreur standard (stderr, descripteur de fichier 2) va au même endroit que la sortie standard (stdout, descripteur de fichier 1, la valeur par défaut pour le côté gauche de >). L' >& outputfileopérateur est un raccourci pour > outputfile 2>&1.

De plus, nouveau dans Bash 4, il y a deux nouveaux terminateurs pour les clauses dans la casecommande ;&et ;;&qui affectent si un cas "tombe" et, si c'est le cas, si le prochain test est effectué.

Dans un script shell Bash, l'esperluette «&» est utilisée pour bifurquer des processus:

find -name hello &

Cela entraînera la commande find à être forkée et exécutée en arrière-plan (vous pouvez toujours la tuer par son PID).

Pourquoi exécuter une commande shell Linux avec '&'?

Pour récupérer immédiatement votre invite et exécuter le processus en arrière-plan.

Quelle est leur fonction?

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 sortie standard et l'erreur standard dans le fichier journal.

& exécute le tout en arrière-plan, vous renvoyant 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 terminent (cela peut être modifié par le programmeur).

Lorsque le shell parent se termine, stdin est fermé sur les enfants et (souvent, généralement) les enfants sortent é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 ici est de quitter également. (Remarque, un programmeur peut changer tout cela lors de l'écriture du programme).

Donc, ce que fait rien est de donner au processus enfant un environnement d'E / S séparé, de lier les tenants et les aboutissants à quelque chose qui n'est pas lié au shell parent, et de protéger l'enfant du signal SIGHUP. Une fois que l'utilisateur se déconnecte, vous verrez le processus d'arrière-plan nohup appartenant à init (processus 1), pas le shell de l'utilisateur.

Cependant, nohupne peut pas faire le travail complètement si le processus est exécuté au premier plan, il &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) est de capturer à la fois stdoutet stderr. Normalement, si vous redirigiez la sortie vers un fichier avec seulement '>', vous n'obtiendrez que la sortie stdout, sans aucune 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écuter la deuxième commande si et seulement si la première commande s'est déroulée avec succès". Une commande bien écrite, si elle contient des erreurs, ne se terminera 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 est d'attendre la commande jusqu'à ce qu'elle se termine. L'esperluette le met en arrière-plan afin que vous obteniez votre invite de terminal et que vous puissiez faire d'autres choses. Si le processus crache des données vers stdout ou stderr, cela sera mélangé avec tout ce que vous faites à l'invite et peut vous confondre. 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 choses que vous avez générées) et ils se terminent généralement. Si vous voulez 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 à fonctionner. Il y a un nom spécial pour ce type de processus, il s'appelle un processus démon (prononcé «démon»).