nohup command is the command you are actually running in this case. The word
firefox is not interpreted by the shell as a command; it is simply passed as an argument to
nohup. What the
nohup command does with that argument is "none of the shell's business".
Of course what
nohup does is to take that argument and runs it as a command.
The point is that what you're actually doing from the shell's point of view is redirecting the output of
nohup, not the output of
nohup will do different things with the output of the command that it runs, depending on where its own output is pointed. From the POSIX specs for
nohup (emphasis added):
If the standard output is a terminal, all output written by the named utility to its standard output shall be appended to the end of the file nohup.out in the current directory. If nohup.out cannot be created or opened for appending, the output shall be appended to the end of the file nohup.out in the directory specified by the HOME environment variable. ...
If standard error is a terminal and standard output is open but is not a terminal, all output written by the named utility to its standard error shall be redirected to the same open file description as the standard output. ...
So due to some inner magic of
nohup, your redirections work as expected if you run:
nohup utility >/dev/null &
Note that you don't need to redirect both
stdout, as the
nohup command will redirect the
stderr of utility depending on where
nohup's own output is pointing to. (Not to mention that
&> isn't portable.)
There is also a portability issue with your input. Since your
stdin is connected to your terminal, it is implementation-specific what will happen with it. (See note under "Rationale" in the
nohup POSIX specs.) Instead you might be better off using:
nohup firefox >/dev/null </dev/null &
And as already mentioned in comments, there is no circumstance with
nohup or any other command where you should ever put a redirection after the backgrounding