LinuxQuestions.org - What is 2>&- mean

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - What is 2>&- mean (https://www.linuxquestions.org/questions/linux-newbie-8/what-is-2-and-mean-903936/)

ust	09-19-2011 10:12 PM

What is 2>&- mean

In my linux system , there is a script that have a 2>&- , I know this is to handle error message , can advise what is this mean ?

Thanks.

corp769

09-19-2011 10:27 PM

Hello,

It is just piping STDERR to the background, running it in the background using the & sign. Have a look here - http://en.wikipedia.org/wiki/Standard_streams
Always remember the following file descriptors:

Code:

0 - STDIN

1 - STDOUT

2 - STDERR

Cheers,

Josh

ust	09-19-2011 10:54 PM

Thx reply,

what is - sign mean ?

corp769

09-19-2011 11:11 PM

Could you show me what the script does, and what output you get? I honestly never used a - with file descriptors.

David the H.

09-20-2011 03:57 PM

Quote:

Originally Posted by corp769 (Post 4476712)

It is just piping STDERR to the background, running it in the background using the & sign.

Incorrect. The &- closes the designated file descriptor. So what it's doing is turning stderr completely off, instead of redirecting it into /dev/null or similar, as scripters usually do.

http://wiki.bash-hackers.org/syntax/redirection

corp769

09-20-2011 06:47 PM

Quote:

Originally Posted by David the H. (Post 4477509)

Ahh, I didn't know that about the dash. Thanks for that man, I even tried looking for that online, but didn't know what it was called, along with being part of the file descriptors.

Reuti

09-20-2011 07:15 PM

Nevertheless there is a difference in closing the file descriptor or redirecting it to /dev/null. To /dev/null you can write to, while writing to a closed file descriptor yields write error: Bad file descriptor.

I would even say the alternative way explained in http://wiki.bash-hackers.org/syntax/redirection is not clean, as the error about not being able to write to stdout can’t also be output. As a consequence the return code of an application made quiet this way might be wrong (i.e. indicating an error).

N.B. It’s in the bash man page in the section about copying file descriptors.

corp769

09-20-2011 07:29 PM

Quote:

Originally Posted by Reuti (Post 4477637)

Nevertheless there is a difference in closing the file descriptor or redirecting it to /dev/null. To /dev/null you can write to, while writing to a closed file descriptor yields write error: Bad file descriptor.

I would even say the alternative way explained in http://wiki.bash-hackers.org/syntax/redirection is not clean, as the error about not being able to write to stdout can’t also be output. As a consequence the return code an application made quiet this way might be wrong (i.e. indicating an error).

N.B. It’s in the bash man page in the section about copying file descriptors.

Ahh, that's why I couldn't find it, I was looking in the wrong places. But after doing the research and fully understanding what it does and how it works, yeah that is true on what you said. You could always run the output before hand to redirect, in that case, to get the output redirected properly.

Reuti

09-21-2011 03:08 AM

It was late this morning. Now with a fresh “proof of error”:

Code:

$ ls >&-

ls: write error: Bad file descriptor

$ echo $?

2

$ ls >/dev/null

$ echo $?

0

Same behavior on AIX: so I think it’s not wise to disregard the output this way. Interesting though, that on Mac OS X it’s really just working as advertised. But I would even this judge as an error: it shouldn’t be possible to write to a closed file descriptor without notifying the user about the error (even a test whether /dev/stdout is writable succeeds, but maybe it’s the way BSD works).

The syntax is fine in case you close a file descriptor you no longer need:

Code:

$ exec 5>foobar

$ echo Hello >&5

$ echo World >&5

$ exec 5>&-

All times are GMT -5. The time now is 12:43 PM.