13

Ive seen tons of examples where a & follows the end of a command string, but I can't seem to find an explanation on what it does. It's not even in nohup's man page. Is this a shell thing?

Either using & or not, I find that any process ran with nohup seems to exhibit immunity to any hangup signal.

Chad Harrison
  • 6,960
  • 10
  • 28
  • 41
  • 1
    "I find that any process ran with nohup seems to exhibit immunity to any hangup signal." That's what nohup is for. – Samuel Edwin Ward Jun 26 '12 at 20:53
  • Ok, so let me clarify: the only examples I've seen uses the `&`, so I wasn't sure if `&` was some sort of modifier or arguement that made `nohup` behave any differently. – Chad Harrison Jun 26 '12 at 21:04
  • 1
    That's a reasonable thing to suspect. In fact it doesn't modify the behaviour nohup (nohup doesn't even get to see it) but modifies the behaviour of the shell. – Samuel Edwin Ward Jun 26 '12 at 22:41
  • nohup& -> No Hangup and background it. From the good old days of modems and serial terminals. When my terminal and modem go offline, keep processing this in the background so the job's done when I next go online. – Fiasco Labs Jul 09 '13 at 17:24

3 Answers3

23

From the bash manpage:

If a command is terminated by the control operator &, the shell executes the command in the background in a subshell. The shell does not wait for the command to finish, and the return status is 0.

So yes, it's a shell thing, and can be used with any command. It essentially returns control to you immediately and allows the command to complete in the background. This is almost always used with nohup because you typically want to exit the shell after starting the command.

mgorven
  • 30,036
  • 7
  • 76
  • 121
9

Using the ampersand (&) will run the command in a child process (child to the current bash session). However, when you exit the session, all child processes will be killed.

using nohup + ampersand (&) will do the same thing, except that when the session ends, the parent of the child process will be changed to "1" which is the "init" process, thus preserving the child from being killed.

Michel
  • 91
  • 1
  • 1
3

Yes, it's a shell thing--it runs the command in the background so you don't have to wait for the current command to return before issuing more commands.

rob
  • 1,253
  • 1
  • 10
  • 17