In Unix, there's several ways to put processes into the background, each with its own different set of effects, because Unix processes have various sorts of connections to your foreground shell session: their process group, whether or not they are ignoring SIGHUP signals, open file descriptors to your tty, and even whether or not the process has a controlling tty.

So, in order of increasing isolation, Unix has:

• simple backgrounding, where you start the program with & and the shell doesn't wait for it to finish. With a job control shell it also means that the process won't get a SIGHUP when you exit the session.

• insulating the process from your session exiting. People using job control shells just redirect standard input, standard output, and standard error away from the tty, because their background processes are already insulated from the end of session SIGHUP. People not using job control shells use nohup to start the program with SIGHUP ignored.

  (nohup also does the redirection for you, if you let it.)

• 'daemonizing' the program, totally detaching it from your terminal. On modern versions of Unix this just requires calling the setsid() system call (as well as redirecting the standard file descriptors and so on); unfortunately this is generally not available in a convenient program for shell scripting.

  (If you are being really thorough you also want to change the current directory to some known good location like /, just so that the daemon doesn't wind up forcing some undesired filesystem to stay mounted.)

For a true daemon program, there are various moderately undesirable effects of still having a controlling terminal (and besides, you can be keeping a pseudo tty busy, preventing it from being reused). Most everything else doesn't care, so most people don't need to worry about achieving full daemonization.