Pourquoi exécuter une commande shell Linux avec &?

En plus des réponses de Martin, Ash et Kevin, parfois, vous verrez une amperse utilisée mathématiquement pour un bitwise AND ^* :

 $ echo $(( 11 & 7 )) 3 

Dans le cas où vous ne connaissez pas les opérateurs de bit:

 11: 1011 7: 0111 -------- AND 3: 0011 

Dans chaque position, il y a un bit dans le premier numéro ET le deuxième nombre, définissez le bit à un dans la réponse.

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

Pour élaborer la réponse de Ash, lorsqu'on l'utilise dans la redirection, l'Etiquette peut indiquer au shell de copier un descripteur de fichier. Dans cette commande echo "hello" > outputfile 2>&1 l' echo "hello" > outputfile 2>&1 toute sortie qui peut aller à une erreur standard (stderr, descripteur de fichier 2) pour aller au même endroit que la sortie standard (stdout, descripteur de fichier 1, par défaut pour Côté gauche de > ). L'opérateur >& outputfile est un raccourci pour > outputfile 2>&1 .

Aussi, nouveau dans Bash 4, il existe deux nouvelles terminaisons pour les clauses dans la commande du case ;& et ;;& qui affectent si un cas "tombe" et, dans l'affirmative, si le prochain test est effectué.

Dans le script bash shell, l'expression "&" est utilisée pour les processus fork:

 find -name hello & 

Est-ce que la commande find sera bifurqué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 revenir immédiatement à votre demande, exécutez le processus en arrière-plan.

Quelle est leur fonction?

Nohup permet à la procédure d'arrière-plan de continuer à fonctionner même après que l'utilisateur se déconnecte (ou quitte le shell initial).

> Et redirige la sortie standard et l'erreur standard dans le fichier journal.

& Exécute tout en arrière-plan, vous remettant immédiatement votre message.

Explication:

Chaque processus Linux ouvre trois canaux E / S, une entrée "stdin", une sortie standard "stdout" et une sortie d'erreur standard "stderr". Ils peuvent être utilisés pour des données binaires mais traditionnellement. Lorsque la plupart des programmes voient stdin fermer, ils sortent (cela peut être modifié par le programmeur).

Lorsque l'enveloppe parent survient, stdin est fermée sur les enfants et (souvent, habituellement) les enfants sortent aussi. En outre, les enfants reçoivent un signal logiciel, SIGHUP, indiquant que l'utilisateur a "raccroché" (anciennement, le modem) et le défaut ici est de sortir aussi. (Notez qu'un programmeur peut changer tout cela lors de l'écriture du programme).

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

Cependant, nohup ne peut pas faire le travail complètement si le processus est exécuté au premier plan, donc, il est utilisé pour exécuter le programme en arrière-plan, où il peut être heureux de fonctionner avec ou sans un utilisateur connecté.

En plus de la réponse de @ Martin: L'autre utilisation de l'amperse ( >& comme ci-dessus) consiste à capturer à la fois stdout et stderr . Normalement, si vous avez redirigé la sortie vers un fichier avec seulement '>', vous n'obtiendrez que la sortie à l'état, manquant toutes les erreurs.

En plus de la réponse de Martin et Ash, parfois, vous pouvez 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 a été exécutée avec succès". Une commande bien écrite, si elle a des erreurs, ne se termine pas avec succès.

 [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'ed et exec'ed, mais le comportement normal de la coque est d'attendre la commande jusqu'à sa sortie. L'amperse le met en arrière-plan pour que vous répondez à votre terminal et que vous puissiez faire d'autres choses. Si le processus crache les données à stdout ou stderr, cela sera mélangé avec ce que vous faites à l'invite et vous confondre. C'est pourquoi vous redirigez ensuite avec> & /path/to/logfile.txt.

En réponse à George2, le comportement normal pour une sortie de shell est d'envoyer le signal SIGHUP à tous les processus dans le même groupe de processus (essentiellement des choses que vous avez engendrées) et elles se terminent habituellement. Si vous voulez que cela continue, même si vous fermez le processus shell, vous pouvez utiliser la commande nohup pour les faire ignorer ce signal et continuer à fonctionner. Il existe un nom spécial pour ce type de processus, on appelle un processus de démon (prononcé «démon»).