After using `exec 1>file`, how can I stop this redirection of the STDOUT to file and restore the normal operation of STDOUT?

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).

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.

$ dateMon Aug 25 10:06:46 CEST 2014$ exec > /tmp/foo$ date$ exec > /dev/tty$ dateMon 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/fooMon 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.

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.txtecho -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 stdinexec 1>&0# Oops... I need to append some more data.# So, lets append to the file.exec 1>> ./output.test.txtecho -e "# Appended this line and the next line is empty.\n"# Send stdout back to stdinexec 1>&0# Output the contents to stdoutcat ./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.