I know that,
nohup being a binary, it can be reached from any shell. But the
exec built-in probably exists in every shell.
Is there a reason to prefer one of them, to the other?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
What's better, a fish or a bicycle?
exec do different things.
exec replaces the shell with another program. Using
exec in a simple background job isn't useful:
exec myprogram; more stuff replaces the shell with
myprogram and so doesn't run
more stuff, unlike
myprogram; more stuff which runs
more stuff when
myprogram terminates; but
exec myprogram & more stuff starts
myprogram in the background and then runs
more stuff, just like
myprogram & more stuff.
nohup runs the specificed program with the SIGHUP signal ignored. When a terminal is closed, the kernel sends SIGHUP to the controlling process in that terminal (i.e. the shell). The shell in turn sends SIGHUP to all the jobs running in the background. Running a job with
nohup prevents it from being killed in this way if the terminal dies (which happens e.g. if you were logged in remotely and the connection drops, or if you close your terminal emulator).
nohup also redirects the program's output to the file
nohup.out. This avoids the program dying because it isn't able to write to its output or error output. Note that
nohup doesn't redirect the input. To fully disconnect a program from the terminal where you launched it, use
nohup myprogram </dev/null >myprogram.log 2>&1 &
The shell built in command
exec <command> replaces the shell with
<command>, no new process, no new PID is created. After completion of
<command> normally your terminal will close. By running it in the background first a subshell is created, which then similarly is immediately replaced by
nohup <command> command will run
<command> but immume to hangups (kill -s 1) so it will not be terminated when the shell, the terminal from which it was started is, is closed. By running it in the background first a subshell is created and the command runs in the background, returning you to the prompt.
In scripting the immediate effect is more or less the same though,
<command> is started by your script and the script will continue without waiting for
<command> to start, to send output or to complete.