After using `exec 1>file`, how can I stop this red

Question

I am a newbie in shell scripting and I am using Ubuntu-11.10. In the terminal after using exec 1>file command, whatever commands I give to terminal, its output doesn't get shown in terminal. I know that STDOUT is getting redirected to the file, the output of those commands gets redirected to file.

My questions are here

1. Once I use exec 1>file, how can I get rid of this? i.e. How can I stop the redirection of STDOUT to file and restore the normal operation of STDOUT (i.e. redirection to terminal rather than file)?

   I tried using exec 1>&- but it didn’t work as this closes the STDOUT file descriptor.

2. Please throw light on this entire operation of exec 1>file and exec 1>&-

3. What will happen if we close the standard file descriptors 0, 1, 2 by using exec 0>&- exec 1>&- exec 2>&-?

Answer 1

Q1

You have to prepare for the recovery before you do the initial exec:

exec 3>&1 1>file

To recover the original standard output later:

exec 1>&3 3>&-

The first exec copies the original file descriptor 1 (standard output) to file descriptor 3, then redirects standard output to the named file. The second exec copies file descriptor 3 to standard output again, and then closes file descriptor 3.

Q2

This is a bit open ended. It can be described at a C code level or at the shell command line level.

exec 1>file

simply redirects the standard output (1) of the shell to the named file. File descriptor one now references the named file; any output written to standard output will go to the file. (Note that prompts in an interactive shell are written to standard error, not standard output.)

exec 1>&-

simply closes the standard output of the shell. Now there is no open file for standard output. Programs may get upset if they are run with no standard output.

Q3

If you close all three of standard input, standard output and standard error, an interactive shell will exit as you close standard input (because it will get EOF when it reads the next command). A shell script will continue running, but programs that it runs may get upset because they're guaranteed 3 open file channels — standard input, standard output, standard error — and when your shell runs them, if there is no other I/O redirection, then they do not get the file channels they were promised and all hell may break loose (and the only way you'll know is that the exit status of the command will probably not be zero — success).

Answer 2

The accepted answer is too verbose for me. So, I decided to sum up an answer to your original answer.

Using Bash version 4.3.39(2)-release

On a x86 32-Bit on Cygwin Machine

GIVEN:

• Stdin is fd #0.
• Stdout is fd #1.
• Stderr is fd #2.

ANSWER (written in bash):

exec 1> ./output.test.txt
echo -e "First Line: Hello World!"
printf "%s\n" "2nd Line: Hello Earth!" "3rd Line: Hello Solar System!"

# This is uneccessary, but
# it stops or closes stdout.
# exec 1>&-

# Send stdout back to stdin
exec 1>&0

# Oops... I need to append some more data.
# So, lets append to the file.
exec 1>> ./output.test.txt
echo -e "# Appended this line and the next line is empty.\n"

# Send stdout back to stdin
exec 1>&0

# Output the contents to stdout
cat ./output.test.txt

USEFUL-KEYWORDS:

There are also here-docs, here-strings, and process-substitution for IO redirection in Bourne, Bash, tcsh, zsh for Linux, BSD, AIX, HP, Busybox, Toybox and etcetera.

Answer 3

While I completely agree with Jonathan's Q1, some systems have /dev/stdout, so you might be able to do exec 1>file; ...; exec 1>/dev/stdout

Answer 4

Q1: There is a simple way to restore stdout to the terminal after it has been redirected to a file:

exec >/dev/tty

While saving the original stdout file descriptor is commonly required for it to be restored later, in this particular case, you want stdout to be /dev/tty so there is no need to do more.

$ date
Mon Aug 25 10:06:46 CEST 2014
$ exec > /tmp/foo
$ date
$ exec > /dev/tty
$ date
Mon Aug 25 10:07:24 CEST 2014
$ ls -l /tmp/foo
-rw-r--r-- 1 jlliagre jlliagre 30 Aug 25 10:07 /tmp/foo
$ cat /tmp/foo
Mon Aug 25 10:07:05 CEST 2014

Q2: exec 1>file is a slightly more verbose way of doing exec >file which, as already stated, redirect stdout to the given file, provided you have the right to create/write it. The file is created if it doesn't exist, it is truncated if it does.

exec 1>&- is closing stdout, which is probably a bad idea in most situations.

Q3: The commands should be

exec 0<&-
exec 1>&-
exec 2>&-

Note the reversed redirection for stdin.

It might be simplified that way:

exec <&- >&- 2>&-

This command closes all three standard file descriptors. This is a very bad idea. Should you want a script to be disconnected from these channels, I would suggest this more robust approach:

exec </dev/null >/dev/null 2>&1

In that case, all output will be discarded instead of triggering an error, and all input will return just nothing instead of failing.