Unterschiede zwischen "<command> & disown" und "nohup <command> & disown"

41

Das ist mein Verständnis über die Nutzung &, disownund nohup:

<command>: Läuft den Prozess innerhalb des aktuellen Terminal bashbeispielsweise im Vordergrund (dh das Verfahren als aufgeführten bashVordergrund Job und stdin, stdoutund stderrimmer noch an das Endgerät gebunden ); nicht immun gegen Hangups ;
<command> &: Läuft den Prozess innerhalb des aktuellen Terminal bashBeispiel im Hintergrund (dh das Verfahren als aufgeführten bashHintergrund Job und stdin, stdoutund stderrsind immer noch an das Endgerät gebunden ); nicht immun gegen Hangups ;
<command> & disown: Läuft den Prozess innerhalb des aktuellen Terminal bashBeispiel im Hintergrund , aber der Prozess wird von den freistehenden bash's Arbeitsplätzen Liste (dh des Prozess aufgeführt ist nicht als bashVordergrund / Hintergrund - Job und stdin, stdoutund stderrist immer noch gebunden an das Terminal ); immun gegen Hangups ;
nohup <command> & disown: Läuft den Prozess innerhalb des aktuellen Terminal bashBeispiel im Hintergrund , aber der Prozess wird von den freistehenden bash's Arbeitsplätzen Liste (dh des Prozess aufgeführt ist nicht als bashVordergrund / Hintergrund - Job und stdin, stdoutund stderrwird nicht noch gebunden an das Terminal ) ; immun gegen Hangups ;

Also, abgesehen von nohup <command> & disownSperrung stdinund Umleitung stdoutund stderrauf nohup.outstandardmäßig scheint es mir , wie es zu völlig gleichwertig betrachtet werden kann <command> & disown.

Ist das vor allem richtig? Irrtum?

— kos
quelle

1

Was meinen Sie mit "immun gegen Aufhänge" und "nicht immun gegen Aufhänge"?

— Chaos

2

@chaos Ich meine, dass das Beenden / Beenden der übergeordneten bashInstanz den Prozess nicht beendet

— kos

32

Ihr Verständnis ist grundsätzlich richtig. Beide disownund nohupwerden verwendet, um das Beenden einer laufenden Shell-Sitzung zu ermöglichen, ohne laufende Jobs zu stoppen. Einige Klarstellungen:

Es gibt keinen Grund zu rennen nohup command & disown, nohupwird es schon für Sie verleugnen.
nohupwird von POSIX definiert, während dies disown nicht der Fall ist . Dies bedeutet , dass während viele Schalen (zB bash, zsh, ksh) es haben, andere (zum Beispiel tcsh, csh, dashund sh) wird es nicht.
disownkann nach dem Start eines Befehls nohupverwendet werden, muss aber zuvor verwendet werden.

Soweit ich das beurteilen kann, ist die tatsächliche Wirkung der beiden Befehle dieselbe. Sie haben alle Eigenschaften, die dem anderen fehlen (siehe help disownund man nohup), aber ihre Grundfunktion ist die gleiche, ja.

Um diese Tools und ihre Unterschiede ausführlicher zu diskutieren, lesen Sie die Antworten hier:

— terdon
quelle

11

Nohupund disownsind nicht dasselbe und beide Befehle zusammen zu verwenden ist NICHT redundant. Siehe diese Antwort für eine ausführliche Beschreibung

— Memo

7

Ihr erster bis dritter Punkt scheinen in Ordnung zu sein, obwohl dies stdin, stdout and stderr are still bound to the terminalkein richtiger Begriff ist. stdinist immer an das Terminal gebunden, in dem Sinne, dass Sie den Dateinamen immer über das Terminal oder über Methoden, die das Terminal verwenden, in einen Befehl eingeben würden. stdout and stderr are still bound to the terminalalles ok.

Ihr habt stdin, stdout and stderr are not still bound to the terminalim vierten Punkt was nicht stimmt wie in meinem vorherigen Absatz erwähnt. Auch hier verwenden Sie /dev/nullals Eingabedatei die command, wenn der Befehl beispielsweise lautet cat, verwenden Sie sie als cat /dev/null.

Der Befehl an Ihrem 5. Punkt ist nicht richtig ausgedrückt, Sie haben ihn verwendet nohup <command> & disown, während Sie den einen nohupoder disownanderen nicht benötigen. Ihre Zwecke sind die gleichen (um das zu ignorieren SIGHUP), aber sie funktionieren auf eine etwas andere Art und Weise. So kann der Befehl so vereinfacht werden nohup <command> &.

— heemayl
quelle