IO Redirection – Restoring Terminal Output After ‘exec &>filename’

io-redirection

I am trying to execute the following:

exec &>filename

After this I am not able to see anything including what I typed, alright.

I frantically try , exec 1>&1 and exec 2>&2 , but nothing happens.

Now , without killing the shell , how do I get back the output redirected to the stdout and error redirected to stderr respectively?
Are the file descriptors the only way to refer standard [in|out]put and stderr?

Best Answer

After you run exec &>filename, the standard output and standard error of the shell go to filename. Standard input is file descriptor 0 by definition, and standard output is fd 1 and standard error is fd 2.

A file descriptor isn't either redirected or non-redirected: it always go somewhere (assuming that the process has this descriptor open). To redirect a file descriptor means to change where it goes. When you ran exec &>filename, stdout and stderr were formerly connected to the terminal, and became connected to filename.

There is always a way to refer to the current terminal: /dev/tty. When a process opens this file, it always means the process's controlling terminal, whichever it is. So if you want to get back that shell's original stdout and stderr, you can do it because the file they were connected to is still around.

exec &>/dev/tty

Related Solutions

Bash – Redirect stderr from an already running script

I think it is possible if you attach the process of the related interpreter to gdb. I tried it with this perl one-liner

 perl -e 'do { print "x\n"; sleep(1) } while(1)'

and it works but unfortunately not with a similar bash script.

First of all you have to figure out the PID of that process whose output you want to capture. Then start gdb in another terminal and execute the following gdb-commands

attach PID
call close(2)
call open("/abs/olu/te/path/filename", 65, 384)
detach PID

after that the whole data that is written to stderr is redirected to /abs/olu/te/path/filename, since

attach PID attaches the process to gdb and stops it
call close(2) closes the stderr filedescriptor of the process (for stdout the filedescriptor is 1)
call open(...) opens a new file and takes the lowest unused integer for the newly created filedescriptor and
detach PID continues the process

At least on my machine. The first two lines are POSIX compatible but not the third one.

The second and the third argument of open in the third line are documented in man 2 open. In my case 65 means that open should create the file and open the file write-only i.e. O_WRONLY | O_CREAT (defined in fcntl.h). The third argument tells open to create the file with read and write permission for the user i.e. S_IWUSR | S_IRUSR (defined in sys/stat.h). So maybe you have to find out appropriate values on your machine by yourself.

Linux – Accidentally used the output redirection > instead of a pipe |

Sadly I suspect you'll need to rewrite it. (If you have backups, this is the time to get them out. If not, I would strongly recommend you set up a backup regime for the future. Lots of options available, but off topic for this answer.)

I find that putting executables in a separate directory, and adding that directory to the PATH is helpful. This way I don't need to reference the executables by explicit path. My preferred programs directory for personal (private) scripts is "$HOME"/bin and it can be added to the program search path with PATH="$HOME/bin:$PATH". Typically this would be added to the shell startup scripts .bash_profile and/or .bashrc.

Finally, there's nothing stopping you removing write permission for yourself on all executable programs:

touch some_executable.py
chmod a+x,a-w some_executable.py    # chmod 555, if you prefer

ls -l some_executable.py
-r-xr-xr-x+ 1 roaima roaima 0 Jun 25 18:33 some_executable.py

echo "The hunting of the Snark" > ./some_executable.py
-bash: ./some_executable.py: Permission denied

Best Answer

Related Solutions

Bash – Redirect stderr from an already running script

Linux – Accidentally used the output redirection > instead of a pipe |

Related Question