Ich habe Schwierigkeiten, das erste Beispiel zu akzeptieren, bei dem Sie den Job im Hintergrund beginnen und Sie sagen, es ließe sich in der Luft, und Sie müssen [Enter] drücken, um fortzufahren.
Beachten Sie, dass jede Ausgabe, die das Hintergrundskript erzeugt, nach der Shell-Eingabeaufforderung gedruckt wird, wodurch die Illusion einer fehlenden Eingabeaufforderung angezeigt wird (tatsächlich ist die Shell-Eingabeaufforderung bereits vorhanden, wird jedoch nach oben gescrollt). Sie müssen nicht die Eingabetaste drücken, um den nächsten Befehl einzugeben!
Das zweite Beispiel ( exec ... &
) macht überhaupt keinen Sinn: Das kaufmännische Und weist die Shell an, den Befehl als parallelen Hintergrundprozess zu starten, während exec
das Shell die Shell anweist, keinen neuen Prozess zu starten und den neuen Befehl "Recycling" des aktuellen Prozesses auszuführen. Technisch gesprochen (sehr vereinfacht): Der Code des Shell-Programms wird durch den Code des aufgerufenen Programms ersetzt.
Fazit:
Sie müssen nicht die [Eingabetaste] drücken (aber es schadet nicht, wenn Sie dies tun)
Da das Shell-Skript trotzdem als parallele Task gestartet wird, kann das kaufmännische Und weggelassen werden.
Die Verwendung
exec
ist absolut sinnvoll, wenn der zu startende Befehl ohnehin der letzte Befehl ist, der vom Skript ausgeführt wird. Wenn Sie also die Shell opfern, wird ein ansonsten nutzloser Prozess eingespart.
[fügte hinzu:] Es kam nur einer in den Sinn, warum Sie denken, Sie müssten [Enter] drücken:
Während der Shell-Prozess die Eingabeaufforderung anzeigt (bis zum nächsten Befehl), werden keine Benachrichtigungen über abgeschlossene Hintergrundprozesse angezeigt.
Sie erhalten die Benachrichtigung nur, wenn die Shell den nächsten Befehl promt anzeigt. Dies kann auch zu der Illusion führen, dass "man die Eingabetaste drücken muss, damit ein Hintergrundprozess beendet werden kann".