As Guido points out above, nohup already redirects standard error for you unless you redirect it to a file. If you're using Linux, it can be instructive to run a simple command under nohup and look at the calls to
dup2(2) immediately before
I doubt you're seeing what you think you're seeing. Let's think about what happens when you say
nohup foo 2>&1
- The shell redirects stderr to stdout.
- It then invokes nohup, which inherits that situation (stderr and stdout using the same file descriptor).
- nohup opens
nohup.out (file descriptor 3), dups it to file descriptor 1, and closes 3.
- nohup notices stderr is not file, and dups file descriptor 1 to 2, too. Thus file descriptors 1 and 2 both refer to
- nohup calls
exec with any arguments provided on the command line (in this case, foo). The new process inherits the file descriptors that nohup set up for it.
From the command line you cannot create a case in which, as you say, nohup only redirects stderr-outputs. nohup always writes stdout and stderr to a file. stdout goes either to one you specify via redirection, or to
nohup.out; stderr follows stdout unless you explicitly redirect it to another file.
The one peculiar aspect of using
2>&1 with nohup is that GNU's version produces a pointless message on stderr, nohup: ignoring input and appending output to ‘nohup.out’. (What other utility writes a message to standard error that amounts to saying, acting per documentation on instructions?) Normally that noise is written to the terminal; under redirection it winds up as the first line of the output file.