Runs a command without hangups.

nohup <command> &
puts command in background and sends its output to nohup.out file it will not die if you log out fromyour shell session ;-)

7
By: gnawa
2009-02-19 14:45:04

1 Alternatives + Submit Alt

What Others Think

i don't want my commands to die, but PLEASE let nohup die. stop using it and welcome to the 1980s and job control. fricking nohup.out files all over the damn place. jesus.
wwest4 · 649 weeks and 5 days ago
so show we how to do the same only with your "job control" thank you.
gnawa · 649 weeks and 5 days ago
Job control is still handy, and necessary, in the shell. Signal handling is really essential for network programming, and this is essentially what you're doing when you detach processes from each other. You're controlling the flow of signals through your processes. exec accomplishes the same thing, without the output file. nohup.out files can get big, and this is one reason not to use it. It detaches the process from the terminal, so when the terminal receives a SIGHUP or SIGKILL, it is not passed through to the child processes. Also see & for background processes, and "jobs" to see what you've placed in the background. Signal handling rocks.
gloriajw · 649 weeks and 5 days ago
nice explanation gloriajw, thank you :D
gnawa · 649 weeks and 5 days ago
modern shells either 1) do not pass sighup/sigkill to backgrounded child procs, or 2) provide a builtin to disown child procs. nohup is 99% obsolete.
wwest4 · 649 weeks and 5 days ago
better use screen for this: http://www.gnu.org/software/screen/screen.html
dizzgo · 649 weeks and 5 days ago
This isn't true in Debian, unfortunately. Sigkill is passed through from bash to child processes. I just taught these young guys I work with about exec, and they thanked me greatly, because they could not figure out what was going on.
gloriajw · 649 weeks and 5 days ago
dizzgo, I came here to say the same thing. Why use hup when screen is everything -- and more?
ozymandias · 649 weeks and 5 days ago
What about doing it this way? (somecommand > /dev/null 2>&1 &) Enclosing your command disowns the process from your terminal (similar to nohup'ing). The '> /dev/null 2>&1 &' redirects standard out and standard error to /dev/null and the & runs the whole thing in the background. Is use this all the time at work to kick off commands that I know are going to take a few hours to run, but I don't care about the output. I run the command, logout and go home. Is there a better way to do it?
hkyeakley · 649 weeks and 5 days ago
gloriajw: in bash the builtin is 'disown' i think, though on most of the boxes i use these days, it's unnecessary. exec is nice. I dig the parenthetical enclosure method... didn't know that orphaned the enclosed command.
wwest4 · 649 weeks and 5 days ago

What do you think?

Any thoughts on this command? Does it work on your machine? Can you do the same thing with only 14 characters?

You must be signed in to comment.

What's this?

commandlinefu.com is the place to record those command-line gems that you return to again and again. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.

Share Your Commands



Stay in the loop…

Follow the Tweets.

Every new command is wrapped in a tweet and posted to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning, there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.

» http://twitter.com/commandlinefu
» http://twitter.com/commandlinefu3
» http://twitter.com/commandlinefu10

Subscribe to the feeds.

Use your favourite RSS aggregator to stay in touch with the latest commands. There are feeds mirroring the 3 Twitter streams as well as for virtually every other subset (users, tags, functions,…):

Subscribe to the feed for: