Hi,
ich möchte gerne einen Befehl vom Terminal, in dem ich ihn abgesetzt habe, abkoppeln. Ich kann das mittels eines "&" am Ende, aber dann weist mich die zsh beim Tippen von "exit" darauf hin, dass noch jobs ausstehen. Ein weiteres "exit" beendet das Terminal problemlos. Der Befehl im Hintergrund wird aber trotz geschlossenem Terminal fehlerfrei ausgeführt, daher würde ich mir das Doppel-"exit" gerne sparen. Gibt es da eine Möglichkeit?
Es gibt mehrere Möglichkeiten,
eine subshell benutzen:
(befehl &)
mit disown:
befehl & disown
mit nohup:
nohup befehl
Exzellent, ich danke herzlich! Mit subshell bekomme ich's hin, läuft formidabel.

Auch wenn's bereits funktioniert, kannst du mir nochmal weiterhelfen, wie der Befehl mit disown und mit nohup abgekoppelt werden kann?
Das hier ist besagter Befehl:
(sleep $1 && zenity --info --text "$2") > /dev/null 2>&1
Ich bekomm's leider nur mit parse-errors hin. Disown funktionierte zwischenzeitlich, aber dann hab ich wohl was geändert und aktuell gibt's einen parse-errors, im Falle von disown "near `disown'" und im Falle von nohup "near `)'".

Und wenn ich die Variante "subshell" richtig lese, benutze ich doch auch in diesem Befehl bereits eine subshell, deren komplette Ausgabe für alle Befehle ich in den Abfluss schicke, oder?
Wenn du Parse-Errors bekommst, wäre es auch hilfreich den Code zu zeigen, der den Parse-Error produziert.

Sollte imho funktionieren:
(sleep $1 && zenity --info --text "$2") > /dev/null 2>&1 &!
Ich benutze screen dafür. Hat den Vorteil, leicht wieder an den Befehl und dessen Ausgabe dran zu kommen.
Kinch schriebWenn du Parse-Errors bekommst, wäre es auch hilfreich den Code zu zeigen, der den Parse-Error produziert.
Hast du vollkommen Recht, sorry.
(sleep $1 && zenity --info --text "$2") > /dev/null 2>&1 disown
=> parse error near `disown'
nohup (sleep $1 && zenity --info --text "$2") > /dev/null 2>&1
=> parse error near `)'
Der hier dagegen funktioniert einwandfrei:
((sleep $1 && zenity --info --text "$2") > /dev/null 2>&1 &)
@Kinch
Dein Code funktioniert auch bestens, danke!

Wiederrankommen muss ich an den Job nicht, daher ist screen ein bisschen Overkill (da das afaik ja ein externes Programm ist, was ich mir extra installieren müsste). Aber danke für den Tipp.
Ovion schrieb
(sleep $1 && zenity --info --text "$2") > /dev/null 2>&1 disown
=> parse error near `disown'
disown entkoppelt immer den letzten job von der shell, du muss aber den disown Aufruf vom eigentlichen Job trennen:
sleep $1 && zenity --info --text "$2" > /dev/null 2>&1 & disown
Ach so, danke, nun laufen auch nohup und disown!

Einen herzlichen Dank!

Große Preisfrage ist nun (auch wenn das vermutlich ein Luxusproblem ist): Kann man eine sinnvolle Aussage darüber treffen, welcher Weg in diesem Falle der sinnvollste ist? Bzw. wo genau liegen die technischen Unterschiede?
command &!
ist äquivalent zu:
command &
disown
Es ist halt kürzer.

'nohup' ist ein externes Commando und damit Shell-Unabhängig. Es frisst halt nur das HUP-Signal; du bekommst aber dennoch ne Warnung, falls du die Shell schließen willst.

Darüberhinaus gibts übrigens auch Optionen zur Jobcontrol:
setopt NO_CHECK_JOBS
setopt NO_HUP
Macht disown und nohup praktisch automatisch, wenn du ein Kommando im Hintergrund laufen lässt.
&! und & disown sollten äquivalent sein, &! ist halt zsh-only währen & disown auch in bash funktioniert.

nohup und disown funktionieren vollkommen unterschiedlich, nohup ist bei den meisten shells kein builtin sondern ein separates programm. nohup sorgt dafür das das Programm kein kontrollierendes Terminal hat und dass kein SIGHUP an das zu startende Programm gesendet wird, zudem macht nohup noch einige redirections, nämlich /dev/null>&0, 1>>nohup.out und 2>&1.

Wenn man ein Programm ohne nohup startet und stattdessen disown verwendet dann hat das Programm natürlich ein kontorllierendes Terminal, disown sorgt einfach dafür dass die Shell kein SIGHUP an das Programm sendet, es sorgt aber nicht dafür dass SIGHUP von dem Programm ignoriert wird.
Wieder was gelernt. Ich danke!

Und die Subshell-Variante ist einfach quasi eine eigene, terminalunabhängige Shell, die vom Terminalschließen nicht betroffen ist und den Prozess "hält"?