Comment puis-je utiliser la commande nohup sans obtenir nohup.out?

Nohup n'écrit dans nohup.out que si la sortie est dans le terminal. Si vous redirigez la sortie de la commande ailleurs-y compris /dev/null - c'est là qu'elle va à la place.

 nohup command >/dev/null 2>&1   # doesn't create nohup.out

Si vous utilisez nohup, cela signifie probablement que vous voulez exécuter la commande en arrière-plan en mettant un autre & à la fin de l'ensemble:

 nohup command >/dev/null 2>&1 & # runs in background, still doesn't create nohup.out

Sous Linux, l'exécution d'un travail avec nohup ferme également automatiquement son entrée. Sur D'autres systèmes, notamment BSD et OS X, c'est-à-dire ce n'est pas le cas, donc lorsque vous exécutez en arrière-plan, vous pouvez fermer son entrée manuellement. Bien que la fermeture de l'entrée n'ait aucun effet sur la création ou non de nohup.out, elle évite un autre problème: si un processus d'arrière-plan essaie de lire quoi que ce soit à partir de l'entrée standard, il fera une pause, en attendant que vous le rameniez au premier plan et tapiez quelque chose. Donc, la version extra-sûre ressemble à ceci:

nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal 

Notez cependant que cela n'empêche pas la commande d'accéder directement au terminal, ni le supprimer de votre coque du processus de groupe. Si vous voulez faire ce dernier, vous pouvez le faire en exécutant disown sans argument comme commande suivante, à quel point le processus n'est plus associé à un "travail" shell et n'aura aucun signaux (pas seulement HUP) transmis à partir du shell.

Explication:

Dans les systèmes Unixy, chaque source d'entrée ou cible de sortie a un nombre associé appelé "descripteur de fichier", ou" fd " pour faire court. Chaque programme en cours d'exécution ("processus") a son propre ensemble de ceux-ci, et quand un nouveau processus démarre, il en a trois déjà ouverts: "entrée standard", qui est fd 0, est ouvert pour que le processus puisse lire, tandis que "sortie standard" (fd 1) et "erreur standard" (fd 2) sont ouverts pour qu'il puisse écrire. Si vous exécutez simplement une commande dans une fenêtre de terminal, alors par défaut, tout ce que vous tapez va à son entrée standard, tandis que sa sortie standard et l'erreur standard sont envoyées à cette fenêtre.

Mais vous pouvez demandez au shell de changer l'endroit où pointent tout ou partie de ces descripteurs de fichier avant de lancer la commande; c'est ce que la redirection (<, <<, >, >>) et les opérateurs pipe (|) font.

Le tuyau est le plus simple d'entre eux... command1 | command2 organise la sortie standard de command1 pour alimenter directement l'entrée standard de command2. C'est un arrangement très pratique qui a conduit à un modèle de conception particulier dans les outils UNIX (et explique l'existence d'une erreur standard, qui permet à un programme d'envoyer des messages à l'utilisateur même si sa sortie va dans le programme suivant dans le pipeline). Mais vous ne pouvez que canaliser la sortie standard vers l'entrée standard; vous ne pouvez pas envoyer d'autres descripteurs de fichier à un tuyau sans jongler.

Les opérateurs de redirection sont plus conviviaux en ce sens qu'ils vous permettent de spécifier le descripteur de fichier à rediriger. Ainsi, 0<infile lit l'entrée standard du fichier nommé infile, tandis que 2>>logfile ajoute l'erreur standard à la fin du fichier nommé logfile. Si vous ne spécifiez pas de nombre, la redirection d'entrée par défaut est fd 0 ({[11] } est identique à 0<), tandis que la redirection de sortie par défaut est fd 1 ({[13] } est identique à 1>).

En outre, vous pouvez combiner des descripteurs de fichiers ensemble: 2>&1 signifie "envoyer une erreur standard partout où la sortie standard va". Cela signifie que vous obtenez un seul flux de sortie qui inclut à la fois standard out et standard error mélangés sans aucun moyen de les séparer, mais cela signifie également que vous pouvez inclure erreur standard dans un tuyau.

Donc, la séquence >/dev/null 2>&1 signifie " envoyer une sortie standard à /dev/null "(qui est un périphérique spécial qui jette tout ce que vous écrivez) "puis envoyer une erreur standard à l'endroit où la sortie standard va" (ce que nous venons de faire était /dev/null). Fondamentalement, "jetez ce que cette commande écrit soit descripteur de fichier".

Lorsque nohup détecte que ni son erreur standard ni sa sortie ne sont attachées à un terminal, cela ne dérange pas créer nohup.out, mais suppose que la sortie est déjà redirigé où l'utilisateur souhaite aller.

Le périphérique /dev/null fonctionne également pour l'entrée; si vous exécutez une commande avec </dev/null, toute tentative de lecture de cette commande à partir d'une entrée standard rencontrera instantanément la fin du fichier. Notez que la syntaxe de fusion n'aura pas le même effet ici; cela ne fonctionne que pour pointer un descripteur de fichier vers un autre qui est ouvert dans la même direction (entrée ou sortie). La coquille vous permettra de faire >/dev/null <&1, mais que les vents créer un processus avec un descripteur de fichier d'entrée ouvert sur un flux de sortie, Donc au lieu de simplement frapper la fin du fichier, toute tentative de lecture déclenchera une erreur fatale "descripteur de fichier invalide".