Currently, I'm using nohup command & to send it in background. But the problem is: if I execute nohup command & I get outout as :

root@ubuntu:/home/test# nohup sleep 10 &
[2] 52439
root@ubuntu:/home/test# nohup: ignoring input and appending output to `nohup.out'
<I need to press ENTER key here to take back my shell control.>

What I need to do :

root@ubuntu:/home/test# nohup sleep 10 &
[2] 52439
root@ubuntu:/home/test# nohup: ignoring input and appending output to `nohup.out'

I don't want to press "ENTER KEY" after nohup sleep 10 &.

As, I'm working on automation part, I need that after one command is sent to background, I should be able to execute next command without pressing any key. Like:

root@ubuntu:/home/test# nohup start-server.py &
root@ubuntu:/home/test# nohup start-client.py &

[start-server.py needs to be running in background.] but the problem is, after start-server.py gets executed, it won't execute next command. I need to press "ENTER KEY" to go for next command.

Is there any solution? Any help would be greatly appreciated.

  • Why are you experimenting with commands as root? Use a non-privileged account.
    – chepner
    May 30 '13 at 12:41
  • 1
    Write your nohup commands in one script say "script.sh" ... and execute it (sh script.sh) ... I hope it should work ... nd yes try a privileged account...
    – Debaditya
    May 30 '13 at 12:42
  • You do not need to press ENTER, nohup is just failing to add a CR at the end off the output. Your shell is still parsing your input.
    – mathk
    May 30 '13 at 13:24
nohup sleep 10 2>/dev/null &

The nohup command prints a message to stderr, and 2>/dev/null sends stderr to /dev/null.

  • Thanks Uwe.. You saved the day..! Your answers was exactly what I was looking for.
    – ShitalSavekar
    May 30 '13 at 12:54

No need for enter. Just type your next command and it will work (what you see is just some output after your shell prompt has been output). This is exactly the same as what happens when you type enter at the shell prompt: you get another prompt. :-)


You don't really need to press Enter. Although it looks like the standard error from nohup is on your command line, you can "type over" it, and only what you type is entered as the next command.


From https://stackoverflow.com/a/10408906/738947

nohup only writes to nohup.out if the output is otherwise to the terminal. If you redirect the output of the command somewhere else - including /dev/null - that's where it goes instead.

 nohup command >/dev/null 2>&1   # doesn't create nohup.out

If you're using nohup, that probably means you want to run the command in the background by putting another & on the end of the whole thing:

 nohup command >/dev/null 2>&1 & # runs in background, still doesn't create nohup.out

On Linux, running a job with nohup automatically closes its input as well. On other systems, notably BSD and OS X, that is not the case, so when running in the background, you might want to close its input manually. While closing input has no effect on the creation or not of nohup.out, it avoids another problem: if a background process tries to read anything from standard input, it will pause, waiting for you to bring it back to the foreground and type something. So the extra-safe version looks like this:

nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal 

Note, however, that this does not prevent the command from accessing the terminal directly, nor does it remove it from your shell's process group. If you want to do the latter, you can do so by running disown with no argument as the next command, at which point the process is no longer associated with a shell "job" and will not have any signals (not just HUP) forwarded to it from the shell.


In Unixy systems, every source of input or target of output has a number associated with it called a "file descriptor", or "fd" for short. Every running program ("process") has its own set of these, and when a new process starts up it has three of them already open: "standard input", which is fd 0, is open for the process to read from, while "standard output" (fd 1) and "standard error" (fd 2) are open for it to write to. If you just run a command in a terminal window, then by default, anything you type goes to its standard input, while both its standard output and standard error get sent to that window.

But you can ask the shell to change where any or all of those file descriptors point before launching the command; that's what the redirection (<, <<, >, >>) and pipe (|) operators do.

The pipe is the simplest of these... command1 | command2 arranges for the standard output of command1 to feed directly into the standard input of command2. This is a very handy arrangement that has led to a particular design pattern in UNIX tools (and explains the existence of standard error, which allows a program to send messages to the user even though its output is going into the next program in the pipeline). But you can only pipe standard output to standard input; you can't send any other file descriptors to a pipe without some juggling.

The redirection operators are friendlier in that they let you specify which file descriptor to redirect. So 0<infile reads standard input from the file named infile, while 2>>logfile appends standard error to the end of the file named logfile. If you don't specify a number, then input redirection defaults to fd 0 (< is the same as 0<), while output redirection defaults to fd 1 (> is the same as 1>).

Also, you can combine file descriptors together: 2>&1 means "send standard error wherever standard output is going". That means that you get a single stream of output that includes both standard out and standard error intermixed with no way to separate them anymore, but it also means that you can include standard error in a pipe.

So the sequence >/dev/null 2>&1 means "send standard output to /dev/null" (which is a special device that just throws away whatever you write to it) "and then send standard error to wherever standard output is going" (which we just made sure was /dev/null). Basically, "throw away whatever this command writes to either file descriptor".

When nohup detects that neither its standard error nor output is attached to a terminal, it doesn't bother to create nohup.out, but assumes that the output is already redirected where the user wants it to go.

The /dev/null device works for input, too; if you run a command with </dev/null, then any attempt by that command to read from standard input will instantly encounter end-of-file. Note that the merge syntax won't have the same effect here; it only works to point a file descriptor to another one that's open in the same direction (input or output). The shell will let you do >/dev/null <&1, but that winds up creating a process with an input file descriptor open on an output stream, so instead of just hitting end-of-file, any read attempt will trigger a fatal "invalid file descriptor" error.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.