the 2 is stderr and 1 is stdout. When you run a program, you'll get the normal output in stdout, but any errors or warnings usually go to stderr. If you want to pipe all output to a file for example, it's useful to first combine stderr with stdout with 2>&1.
Like @cma said, it puts stderr on stdout. The reason you might want this behavior is to use grep or any other utility to capture output that only appears on stderr. Or you might just want to save all the output, including stderr, to a file for later processing.
One quite useful application of exec 2>&1 that I have come across is when you want to merge stderr and stdout for several commands separated by semicolons. My particular example happened when I was sending more than one command to popen in PHP and I wanted to see the errors interleaved like you would see if you typed the commands at a shell prompt:
$ echo hi ; yikes ; echo there
hi
-bash: yikes: command not found
there
$
The following does not merge stderr and stdout except for the last echo (which is pointless because the yikes causes the error):
echo hi ; yikes ; echo there 2>&1
I can get the merged output the "hard way" as follows:
echo hi 2>&1; yikes 2>&1; echo there 2>&1
It looks a lot cleaner and less error prone if you use exec:
exec 2>&1 ; echo hi; echo yikes; echo there
You get the stdout and stderr output nicely interleaved exactly as you would see on the terminal if you executed the three commands separated by a semicolon.
Technically speaking it duplicates, or copies, stderr onto stdout.
Usually you don't need the exec to perform this. A more typical use of exec with file descriptors is to indicate that you want to assign a file to an unused file descriptor, e.g.
exec 35< my_input
BTW Don't forget that the sequence of declaration when piping to a file is important, so
ls > mydirlist 2>&1
will work because it directs both stdout and stderr to the file mydirlist, whereas the command
ls 2>&1 > mydirlist
directs only stdout, and not stderr, to file mydirlist, because stderr was made a copy of stdout before stdout was redirected to mydirlist.
Edit: It's the way that the shell works scanning from left to right. So read the second one as saying "copy stderr onto stdout" before it says "send stdout to mydirlist". Then read the first one as saying "send stdout to the file mydirlist" before it says "duplicate stderr onto that stdout I've set up". I know. It's totally not intuitive!
But what the current answers on this question fail to provide is why you'd want to do this after a plain "exec". As the bash man page for the exec command explains: "If command is not specified, any redirections take effect in the current shell".
I wrote a simple script called out-and-err.py that writes a line of output to stdout, and another line to stderr:
#!/usr/bin/python
import sys
sys.stdout.write('this is stdout.\n')
sys.stderr.write('this is stderr.\n')
And then I wrapped that in a shell script called out-and-err.sh with an "exec 2>&1":
#!/bin/bash
exec 2>&1
./out-and-err.py
If I run just the python script, stdout and stderr are separate:
$ ./out-and-err.py 1> out 2> err
$ cat out
this is stdout.
$ cat err
the is stderr.
But if I run the shell script, you can see that the exec takes care of stderr for everything after:
$ ./out-and-err.sh 1> out 2> err
$ cat out
this is stdout.
this is stderr.
$ cat err
$
If your wrapping shell script does a lot more than just the one python command, and you need all output combined into stdout, doing the "exec 2>&1" will make that easy for you.
These day I was suck at this problem too, but now I'm jump out from it.
So, please allow me to explain what happen after you input exec 1>&2 in CLI.
I want to destruct the problem piece by piece, so if you know the knowledge alread just skim it to save your time.
What is exec stands for:
exec is a built-in command in Linux. Different from the tradition command which just fork a sub shell process, exec could change current shell process.
What is I/O redirection:
Redirection is a feature in Linux. With this you can change the standard input/output devices. In Linux, there are three file descriptors by default.
Handle Name Description
0 stdin Standard input
1 stdout Standard output
2 stderr Standard error
Let me see an example:
open a new terminal
Get the termianl process process ID
$ pstree -p | grep 'term' | tr -d ' '
Check the process file descriptor.
$ sudo ls -l /proc/{pid}/fdbash
$ pstree -p | grep -i 'terminal' | tr -d ' '
||||-gnome-terminal-(6008)-+-bash(7641)-+-grep(8355)
$ sudo ls -l /proc/7641/fd
total 0
lrwx------ 1 alopex alopex 64 Oct 27 19:39 0 -> /dev/pts/3
lrwx------ 1 alopex alopex 64 Oct 27 19:39 1 -> /dev/pts/3
lrwx------ 1 alopex alopex 64 Oct 27 19:39 2 -> /dev/pts/3
lrwx------ 1 alopex alopex 64 Oct 27 19:39 255 -> /dev/pts/3
As you can see, the ls list the PID(6860) process file. First they all name by number(0, 1, 2), second they all link file link to /dev/pts/3, it means whatever standard input/output/error all will show up in pts3.
Change the standard output to /tmp/stdout
bash
$ ls /tmp/stdout
ls: cannot access '/tmp/stdout': No such file or directory
$ exec 1>/tmp/stdout
$ ls
$ pwd
$ echo "Are you ok"
$
The command output was disappear at that time.
Open a new terminal, to check the proc file
bash
$ sudo ls -l /proc/7641/fd
total 0
lrwx------ 1 alopex alopex 64 Oct 27 19:39 0 -> /dev/pts/3
lrwx------ 1 alopex alopex 64 Oct 27 19:39 1 -> /tmp/stdout
lrwx------ 1 alopex alopex 64 Oct 27 19:39 2 -> /dev/pts/3
lrwx------ 1 alopex alopex 64 Oct 27 19:39 255 -> /dev/pts/3
Obviously, we can notice that the 1(file descriptor) already change link to /tmp/stdout. As us except, the standard output transfer to /tmp/stdout
Restore the redirection.
bash
$ exec 1>&2
$ cat /tmp/stdout
a.sh
/home/alopex
Are you ok
$ sudo ls -l /proc/7641/fd
total 0
lrwx------ 1 alopex alopex 64 Oct 27 19:39 0 -> /dev/pts/3
lrwx------ 1 alopex alopex 64 Oct 27 19:39 1 -> /dev/pts/3
lrwx------ 1 alopex alopex 64 Oct 27 19:39 2 -> /dev/pts/3
lrwx------ 1 alopex alopex 64 Oct 27 19:39 255 -> /dev/pts/3
Again, the 1(file descriptor) link to the /dev/pts/3, we can see the output again.
Summary:
exec 1>&2 make the standard output ---> standard error
It ties standard error to standard out
the
2
is stderr and1
is stdout. When you run a program, you'll get the normal output in stdout, but any errors or warnings usually go to stderr. If you want to pipe all output to a file for example, it's useful to first combine stderr with stdout with2>&1
.Like @cma said, it puts stderr on stdout. The reason you might want this behavior is to use grep or any other utility to capture output that only appears on stderr. Or you might just want to save all the output, including stderr, to a file for later processing.
One quite useful application of
exec 2>&1
that I have come across is when you want to mergestderr
andstdout
for several commands separated by semicolons. My particular example happened when I was sending more than one command topopen
in PHP and I wanted to see the errors interleaved like you would see if you typed the commands at a shell prompt:The following does not merge
stderr
andstdout
except for the lastecho
(which is pointless because theyikes
causes the error):I can get the merged output the "hard way" as follows:
It looks a lot cleaner and less error prone if you use
exec
:You get the
stdout
andstderr
output nicely interleaved exactly as you would see on the terminal if you executed the three commands separated by a semicolon.Technically speaking it duplicates, or copies, stderr onto stdout.
Usually you don't need the exec to perform this. A more typical use of exec with file descriptors is to indicate that you want to assign a file to an unused file descriptor, e.g.
BTW Don't forget that the sequence of declaration when piping to a file is important, so
will work because it directs both stdout and stderr to the file mydirlist, whereas the command
directs only stdout, and not stderr, to file mydirlist, because stderr was made a copy of stdout before stdout was redirected to mydirlist.
Edit: It's the way that the shell works scanning from left to right. So read the second one as saying "copy stderr onto stdout" before it says "send stdout to mydirlist". Then read the first one as saying "send stdout to the file mydirlist" before it says "duplicate stderr onto that stdout I've set up". I know. It's totally not intuitive!
One of the better articles I've seen on what "2>&1" does is Bash One-Liners Explained, Part III: All about redirections.
But what the current answers on this question fail to provide is why you'd want to do this after a plain "exec". As the bash man page for the exec command explains: "If command is not specified, any redirections take effect in the current shell".
I wrote a simple script called
out-and-err.py
that writes a line of output to stdout, and another line to stderr:And then I wrapped that in a shell script called out-and-err.sh with an "exec 2>&1":
If I run just the python script, stdout and stderr are separate:
But if I run the shell script, you can see that the exec takes care of stderr for everything after:
If your wrapping shell script does a lot more than just the one python command, and you need all output combined into stdout, doing the "exec 2>&1" will make that easy for you.
These day I was suck at this problem too, but now I'm jump out from it. So, please allow me to explain what happen after you input
exec 1>&2
in CLI.I want to destruct the problem piece by piece, so if you know the knowledge alread just skim it to save your time.
exec
stands for:exec
is a built-in command in Linux. Different from the tradition command which just fork a sub shell process,exec
could change current shell process.What is I/O redirection: Redirection is a feature in Linux. With this you can change the standard input/output devices. In Linux, there are three file descriptors by default.
Handle Name Description 0 stdin Standard input 1 stdout Standard output 2 stderr Standard error
Let me see an example:
$ pstree -p | grep 'term' | tr -d ' '
$ sudo ls -l /proc/{pid}/fd
bash $ pstree -p | grep -i 'terminal' | tr -d ' ' ||||-gnome-terminal-(6008)-+-bash(7641)-+-grep(8355) $ sudo ls -l /proc/7641/fd total 0 lrwx------ 1 alopex alopex 64 Oct 27 19:39 0 -> /dev/pts/3 lrwx------ 1 alopex alopex 64 Oct 27 19:39 1 -> /dev/pts/3 lrwx------ 1 alopex alopex 64 Oct 27 19:39 2 -> /dev/pts/3 lrwx------ 1 alopex alopex 64 Oct 27 19:39 255 -> /dev/pts/3
As you can see, thels
list the PID(6860) process file. First they all name by number(0, 1, 2), second they all link file link to /dev/pts/3, it means whatever standard input/output/error all will show up in pts3.bash $ ls /tmp/stdout ls: cannot access '/tmp/stdout': No such file or directory $ exec 1>/tmp/stdout $ ls $ pwd $ echo "Are you ok" $
The command output was disappear at that time.bash $ sudo ls -l /proc/7641/fd total 0 lrwx------ 1 alopex alopex 64 Oct 27 19:39 0 -> /dev/pts/3 lrwx------ 1 alopex alopex 64 Oct 27 19:39 1 -> /tmp/stdout lrwx------ 1 alopex alopex 64 Oct 27 19:39 2 -> /dev/pts/3 lrwx------ 1 alopex alopex 64 Oct 27 19:39 255 -> /dev/pts/3
Obviously, we can notice that the 1(file descriptor) already change link to /tmp/stdout. As us except, the standard output transfer to /tmp/stdoutbash $ exec 1>&2 $ cat /tmp/stdout a.sh /home/alopex Are you ok $ sudo ls -l /proc/7641/fd total 0 lrwx------ 1 alopex alopex 64 Oct 27 19:39 0 -> /dev/pts/3 lrwx------ 1 alopex alopex 64 Oct 27 19:39 1 -> /dev/pts/3 lrwx------ 1 alopex alopex 64 Oct 27 19:39 2 -> /dev/pts/3 lrwx------ 1 alopex alopex 64 Oct 27 19:39 255 -> /dev/pts/3
Again, the 1(file descriptor) link to the /dev/pts/3, we can see the output again.Summary:
exec 1>&2
make the standard output ---> standard error