I'm trying to prevent a GUI program, which was started from the terminal, to write into the console. To do this, I run guiprogram >&-. This leads the program to freeze on some operations.

What does the >&- operator exactly do? What's the intended purpose of it? Can you give any examples? Is it legit to prevent writing into the console by the use of it? Why does the program freeze when closing the standard output?

closed as too broad by Jesse_b, Kusalananda, G-Man, Archemar, Isaac Apr 1 '18 at 22:10

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    What do you mean by "log into the console"? Do you mean preventing it from writing to the terminal? Just redirect its output to /dev/null. – Kusalananda Mar 31 '18 at 11:19
  • 1
    As to What does the &- operator exactly do? you gave the answer already: It closes the standard output. – kiamlaluno Mar 31 '18 at 11:37
  • 1
    If the program doesn't expect, it, on first opening of any random file (or pipe, or socket, or ...), it will get the first fd available: the one you closed. Now because the program logs into the console, it logs into this random file instead. So Don't Do This (tm). Redirect to /dev/null – A.B Mar 31 '18 at 13:18

If you want to prevent the output from a program to appear anywhere redirect to /dev/null:

guiprogram >/dev/null 2>&1

Closing stdout only works if the program knows how to deal with closed files.

A practical use of >&- is rare, you can use it if you afterwards assign another output destination to stdout and want to be sure the original output channel got properly closed.


You would have to look at the source code in order to know why the program freezes. It could abort or crash as well or ignore the problem:

bash -c 'exec >&-; echo foo; echo bar >&2'
    bash: line 0: echo: write error: Bad file descriptor

This shell code ignores the problem.

bash -c 'set -e; exec >&-; echo foo; echo bar >&2'
    bash: line 0: echo: write error: Bad file descriptor

This shell code aborts due to the error.

A freeze may occur if there is some kind of logging function with a loop "repeat until it has been successfully logged". This never happens because the write to file descriptor 1 fails so the program is caught in an endless loop.

  • Why to close the stdout? What's the point of it? Could you give a typical use case for >&-? – Shamaoke Mar 31 '18 at 12:41
  • 2
    @Shamaoke That was your idea, not mine. I am just commenting about the consequences because you asked. I think there is not a single case where this is useful. – Hauke Laging Mar 31 '18 at 12:58
  • @Hauke Laging I appreciate your answer. I just want to understand, why this operator was invented and how to properly use it? Also I want to know, is it formally legit to prevent output from a program by the use of this operator? Suppose I use it for that purpose and the program freezes, whose to blame for that: me, for improper usage or the program author for not verifying that the FD is open before writing to it? – Shamaoke Mar 31 '18 at 13:36
  • @Shamaoke The typical use is to close additional FDs which you have opened before: exec 3>/path/to/file; : do something ; exec 3>&-; exec 3>/path/to/another/file ; : ... – Hauke Laging Mar 31 '18 at 13:39

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