Return to Question

I edited an answer on Ask Ubuntu that was suggesting the following

nohup gedit >& /dev/null & 

When they actually meant

nohup gedit &> /dev/null & 

The latter correctly redirects both stderr and stdout to /dev/null. I was expecting the former to either create a file called & or, more likely, to give an error as it does for other cases:

$ echo "foo" >& 
bash: syntax error near unexpected token `newline'

Instead, it seems to work in exactly the same way as the former, a gedit window appears and no error message is printed.

I should also note that this is shell specific:

• bash (4.2.45(1)-release), zsh (5.0.2), csh (deb package version: 20110502-2) and tcsh (6.18.01) : works as described above, no error message, no files created.

• dash (0.5.7-3):

    $ nohup gedit >& /dev/null & 
    $ dash: 2: Syntax error: Bad fd number
  

• ksh (93u+ 2012-08-01): fails, but a process is apparently started (1223) though no gedit window appears:

    $ nohup gedit >& /dev/null & 
    [1] 1223
    $ ksh: /dev/null: bad file unit number
  

• fish (2.0.0):

    > nohup gedit >& /dev/null & 
    fish: Requested redirection to something that is not a file descriptor /dev/null
    nohup gedit >& /dev/null & 
                   ^
  

So, why does this command simply run with no errors (and no output file created) in some shells and fail in others? What is the >& doing in the apparently special case of nohup? I am guessing that >& /dev/null is being interpreted as >&/dev/null but why isn't the space causing an error in these shells?

I edited an answer on Ask Ubuntu that was suggesting the following

nohup gedit >& /dev/null & 

When they actually meant

nohup gedit &> /dev/null & 

The latter correctly redirects both stderr and stdout to /dev/null. I was expecting the former to either create a file called & or, more likely, to give an error as it does for other cases:

$ echo "foo" >& 
bash: syntax error near unexpected token `newline'

Instead, it seems to work in exactly the same way as the former, a gedit window appears and no error message is printed.

I should also note that this is shell specific:

• bash (4.2.45(1)-release), zsh (5.0.2), csh (deb package version: 20110502-2) and tcsh (6.18.01) : works as described above, no error message, no files created.

• dash (0.5.7-3):

    $ nohup gedit >& /dev/null & 
    $ dash: 2: Syntax error: Bad fd number
  

• ksh (93u+ 2012-08-01): fails, but a process is apparently started (1223) though no gedit window appears:

    $ nohup gedit >& /dev/null & 
    [1] 1223
    $ ksh: /dev/null: bad file unit number
  

• fish (2.0.0):

    > nohup gedit >& /dev/null & 
    fish: Requested redirection to something that is not a file descriptor /dev/null
    nohup gedit >& /dev/null & 
                   ^
  

So, why does this command simply run with no errors (and no output file created) in some shells and fail in others? What is the >& doing in the apparently special case of nohup? I am guessing that >& /dev/null is being interpreted as >&/dev/null but why isn't the space causing an error in these shells?

I edited an answer on Ask Ubuntu that was suggesting the following

nohup gedit >& /dev/null & 

When they actually meant

nohup gedit &> /dev/null & 

Now, the latter correctly redirects both stderr and stdout to /dev/null, I was expecting the former to either create a file called & or, more likely, to give an error as it does for other cases:

$ echo "foo" >& 
bash: syntax error near unexpected token `newline'

Instead, it seems to work in exactly the same way as the former, a gedit window appears and no error message is printed.

I should also note that this is shell specific:

• bash (4.2.45(1)-release), zsh (5.0.2), csh (deb package version: 20110502-2) and tcsh (6.18.01) : works as described above, no error message, no files created.

• dash (0.5.7-3):

    $ nohup gedit >& /dev/null & 
    $ dash: 2: Syntax error: Bad fd number
  

• ksh (93u+ 2012-08-01): fails, but a process is apparently started (1223) though no gedit window appears:

    $ nohup gedit >& /dev/null & 
    [1] 1223
    $ ksh: /dev/null: bad file unit number
  

• fish (2.0.0):

    > nohup gedit >& /dev/null & 
    fish: Requested redirection to something that is not a file descriptor /dev/null
    nohup gedit >& /dev/null & 
                   ^
  

So, why does this command simply run with no errors (and no output file created) in some shells and fail in other? What is the >& doing in the apparently special case of nohup? I am guessing that >& /dev/null is being interpreted as >&/dev/null but why isn't the space causing an error in these shells?

I edited an answer on Ask Ubuntu that was suggesting the following

nohup gedit >& /dev/null & 

When they actually meant

nohup gedit &> /dev/null & 

The latter correctly redirects both stderr and stdout to /dev/null. I was expecting the former to either create a file called & or, more likely, to give an error as it does for other cases:

$ echo "foo" >& 
bash: syntax error near unexpected token `newline'

Instead, it seems to work in exactly the same way as the former, a gedit window appears and no error message is printed.

I should also note that this is shell specific:

• bash (4.2.45(1)-release), zsh (5.0.2), csh (deb package version: 20110502-2) and tcsh (6.18.01) : works as described above, no error message, no files created.

• dash (0.5.7-3):

    $ nohup gedit >& /dev/null & 
    $ dash: 2: Syntax error: Bad fd number
  

• ksh (93u+ 2012-08-01): fails, but a process is apparently started (1223) though no gedit window appears:

    $ nohup gedit >& /dev/null & 
    [1] 1223
    $ ksh: /dev/null: bad file unit number
  

• fish (2.0.0):

    > nohup gedit >& /dev/null & 
    fish: Requested redirection to something that is not a file descriptor /dev/null
    nohup gedit >& /dev/null & 
                   ^
  

So, why does this command simply run with no errors (and no output file created) in some shells and fail in others? What is the >& doing in the apparently special case of nohup? I am guessing that >& /dev/null is being interpreted as >&/dev/null but why isn't the space causing an error in these shells?

I edited an answer on Ask Ubuntu that was suggesting the following

nohup gedit >& /dev/null & 

When they actually meant

nohup gedit &> /dev/null & 

Now, the latter correctly redirects both stderr and stdout to /dev/null, I was expecting the former to either create a file called & or, more likely, to give an error as it does for other cases:

$ echo "foo" >& 
bash: syntax error near unexpected token `newline'

Instead, it seems to work in exactly the same way as the former, a gedit window appears and no error message is printed.

I should also note that this is shell specific:

• bash (4.2.45(1)-release), zsh (5.0.2), csh (deb package version: 20110502-2) and tcsh (6.18.01) : works as described above, no error message, no files created.

• dash (0.5.7-3):

    $ nohup gedit >& /dev/null & 
    $ dash: 2: Syntax error: Bad fd number
  

• ksh (93u+ 2012-08-01): fails, but a process is apparently started (1223) though no gedit window appears:

    $ nohup gedit >& /dev/null & 
    [1] 1223
    $ ksh: /dev/null: bad file unit number
  

• fish (2.0.0):

    > nohup gedit >& /dev/null & 
    fish: Requested redirection to something that is not a file descriptor /dev/null
    nohup gedit >& /dev/null & 
                   ^
  

So, why does this command simply run with no errors (and no output file created) in some shells and fail in other? What is the >& doing in the apparently special case of nohup? I am guessing that >& /dev/null is being interpreted as >&/dev/null but why isn't the space causing an error in these shells?

EDIT: I now understand what's going on a bit better (see my answer) but am still curious for the details. Why do some shells allow this? Where is this documented? Does $IFS splitting come into it somehow?

I edited an answer on Ask Ubuntu that was suggesting the following

nohup gedit >& /dev/null & 

When they actually meant

nohup gedit &> /dev/null & 

Now, the latter correctly redirects both stderr and stdout to /dev/null, I was expecting the former to either create a file called & or, more likely, to give an error as it does for other cases:

$ echo "foo" >& 
bash: syntax error near unexpected token `newline'

Instead, it seems to work in exactly the same way as the former, a gedit window appears and no error message is printed.

I should also note that this is shell specific:

• bash (4.2.45(1)-release), zsh (5.0.2), csh (deb package version: 20110502-2) and tcsh (6.18.01) : works as described above, no error message, no files created.

• dash (0.5.7-3):

    $ nohup gedit >& /dev/null & 
    $ dash: 2: Syntax error: Bad fd number
  

• ksh (93u+ 2012-08-01): fails, but a process is apparently started (1223) though no gedit window appears:

    $ nohup gedit >& /dev/null & 
    [1] 1223
    $ ksh: /dev/null: bad file unit number
  

• fish (2.0.0):

    > nohup gedit >& /dev/null & 
    fish: Requested redirection to something that is not a file descriptor /dev/null
    nohup gedit >& /dev/null & 
                   ^
  

So, why does this command simply run with no errors (and no output file created) in some shells and fail in other? What is the >& doing in the apparently special case of nohup? I am guessing that >& /dev/null is being interpreted as >&/dev/null but why isn't the space causing an error in these shells?