Par exemple, lorsque je tape ping 8.8.8.8 &, pourquoi pouvons-nous voir le processus de ping fonctionner? Et quand je tape find / -name '*test*' &, c'est également visible sur l'écran.
Pourquoi est-ce ainsi? N'est-ce pas vraiment en arrière-plan?
Le & indique au shell d'exécuter la commande en arrière-plan, c'est-à-dire qu'elle est forkée et exécutée dans un sous-shell séparé, en tant que tâche, de manière asynchrone.
Remarquez que lorsque vous mettez &, la sortie - à la fois stdout et stderr - sera toujours affichée à l'écran. Si vous ne voulez pas voir de sortie sur l'écran, redirigez à la fois stdout et stderr vers un fichier en faisant :
monscript > ~/monscript.log 2>&1 &En général, vous pouvez vouloir ignorer le stderr en le redirigeant vers /dev/null si vous ne vous souciez pas d'analyser les erreurs plus tard.
Vous pouvez également exécuter des commandes/scripts en même temps, dans des sous-shells séparés. Par exemple ;
./script1 & ./script2 & ./script3 & Une tâche en arrière-plan peut être ramenée à l'invite de commande avant son achèvement avec la commande :
fg Le numero-de-tache peut être obtenu en exécutant
jobs
Lorsque vous utilisez &, le processus s'exécute en arrière-plan. Mais sa sortie standard est toujours le terminal.
En fait, vous pouvez exécuter ping 8.8.8.8 & et find / -name '*test*' & en même temps (résultant en une sortie mélangée), mais vous ne pouvez pas exécuter ping 8.8.8.8 et find / -name '*test*' en même temps sur le même shell.
Si vous ne voulez rien voir, utilisez quelque chose comme ping 8.8.8.8 &> /dev/null &.
De plus, vous voudrez peut-être en apprendre davantage sur nohup et disown.
Je voulais essayer de répondre spécifiquement à la question du "pourquoi" :
Pourquoi est-ce que c'est ainsi?
L'implémentation POSIX de la gestion des tâches choisit de connecter STDOUT et STDERR au terminal parent[1]. Je soupçonne que c'était le choix par défaut historiquement peut-être parce qu'il n'y avait qu'un seul terminal physique et pas d'émulateurs à l'époque, et donc le terminal était le seul choix où tous les travaux pouvaient écrire leur sortie(?)
Et il semble plutôt difficile de récupérer STDOUT/ERR si vous avez créé le terminal sans un programme comme screen et que votre terminal et le shell dedans sont inaccessibles ou susceptibles de se terminer si vous fermez votre SSH : https://superuser.com/questions/50058/after-the-fact-remote-nohup-with-tcsh/50077#50077 Bien que comme l'indique la réponse là-bas, cela pourrait être fait en attachant gdb si le shell parent a abandonné le processus. C'est aussi une raison importante pour laquelle les émulateurs de terminal sont si utiles car les processus interactifs ne peuvent généralement pas survivre sans chacun ayant son propre terminal.
[1] https://www.gnu.org/software/libc/manual/html_node/Access-to-the-Terminal.html
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
