Redirect all subsequent commands' stderr using exec
Clash Royale CLAN TAG#URR8PPP
I have a bash file that I need to redirect all output to one file, debug log as well as to the terminal. I need to redirect both stdout and stderr to the debug and log it for all commands in the script.
I do not want to add 2>&1 | tee -a $DEBUG
for every single command in the file. I could live with | tee -a $DEBUG
.
I remember there was a way to do it with something like exec 2>&1
.
Currently I'm using something like the following:
#!/bin/bash
DEBUGLOG=/tmp/debug
exec 2>&1
somecommand | tee -a $DEBUGLOG
somecommand2 | tee -a $DEBUGLOG
somecommand3 | tee -a $DEBUGLOG
but it does not work. Does anyone have a solution/can explain the cause?
bash io-redirection
add a comment |
I have a bash file that I need to redirect all output to one file, debug log as well as to the terminal. I need to redirect both stdout and stderr to the debug and log it for all commands in the script.
I do not want to add 2>&1 | tee -a $DEBUG
for every single command in the file. I could live with | tee -a $DEBUG
.
I remember there was a way to do it with something like exec 2>&1
.
Currently I'm using something like the following:
#!/bin/bash
DEBUGLOG=/tmp/debug
exec 2>&1
somecommand | tee -a $DEBUGLOG
somecommand2 | tee -a $DEBUGLOG
somecommand3 | tee -a $DEBUGLOG
but it does not work. Does anyone have a solution/can explain the cause?
bash io-redirection
1
In some shells,|&
works as a shortcut for2>&1 |
, it's at least slightly more convenient.
– Kevin
Jan 20 '13 at 18:12
add a comment |
I have a bash file that I need to redirect all output to one file, debug log as well as to the terminal. I need to redirect both stdout and stderr to the debug and log it for all commands in the script.
I do not want to add 2>&1 | tee -a $DEBUG
for every single command in the file. I could live with | tee -a $DEBUG
.
I remember there was a way to do it with something like exec 2>&1
.
Currently I'm using something like the following:
#!/bin/bash
DEBUGLOG=/tmp/debug
exec 2>&1
somecommand | tee -a $DEBUGLOG
somecommand2 | tee -a $DEBUGLOG
somecommand3 | tee -a $DEBUGLOG
but it does not work. Does anyone have a solution/can explain the cause?
bash io-redirection
I have a bash file that I need to redirect all output to one file, debug log as well as to the terminal. I need to redirect both stdout and stderr to the debug and log it for all commands in the script.
I do not want to add 2>&1 | tee -a $DEBUG
for every single command in the file. I could live with | tee -a $DEBUG
.
I remember there was a way to do it with something like exec 2>&1
.
Currently I'm using something like the following:
#!/bin/bash
DEBUGLOG=/tmp/debug
exec 2>&1
somecommand | tee -a $DEBUGLOG
somecommand2 | tee -a $DEBUGLOG
somecommand3 | tee -a $DEBUGLOG
but it does not work. Does anyone have a solution/can explain the cause?
bash io-redirection
bash io-redirection
edited Sep 9 '16 at 7:52
Greg Dubicki
15013
15013
asked Jan 20 '13 at 18:01
AviAvi
198124
198124
1
In some shells,|&
works as a shortcut for2>&1 |
, it's at least slightly more convenient.
– Kevin
Jan 20 '13 at 18:12
add a comment |
1
In some shells,|&
works as a shortcut for2>&1 |
, it's at least slightly more convenient.
– Kevin
Jan 20 '13 at 18:12
1
1
In some shells,
|&
works as a shortcut for 2>&1 |
, it's at least slightly more convenient.– Kevin
Jan 20 '13 at 18:12
In some shells,
|&
works as a shortcut for 2>&1 |
, it's at least slightly more convenient.– Kevin
Jan 20 '13 at 18:12
add a comment |
3 Answers
3
active
oldest
votes
As for a solution to redirect lots of command at once:
#!/bin/bash
somecommand
somecommand2
somecommand3
2>&1 | tee -a $DEBUGLOG
Why your original solution does not work: exec 2>&1 will redirect the standard error output to the standard output of your shell, which, if you run your script from the console, will be your console. the pipe redirection on commands will only redirect the standart output of the command.
On the point of view of somecommand
, its standard output goes into a pipe connected to tee
and the standard error goes into the same file/pseudofile as the standard error of the shell, which you redirect to the standard output of the shell, which will be the console if you run your program from the console.
The one true way to explain it is to see what really happens:
Your shell's original environment might look like this if you run it from the terminal:
stdin -> /dev/pts/42
stdout -> /dev/pts/42
stderr -> /dev/pts/42
After you redirect standard error into standard output (exec 2>&1
), you ... basically change nothing. But if you redirect the script's standart output to a file, you would end up with an environment like this:
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /dev/pts/42
Then redirecting the shell standard error into standard output would end up like this :
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /your/file
Running a command will inherit this environment. If you run a command and pipe it to tee, the command's environment would be :
stdin -> /dev/pts/42
stdout -> pipe:[4242]
stderr -> /your/file
So your command's standard error still goes into what the shell uses as its standard error.
You can actually see the environment of a command by looking in /proc/[pid]/fd
: use ls -l
to also list the symbolic link's content. The 0
file here is standard input, 1
is standard output and 2
is standard error. If the command opens more files (and most programs do), you will also see them. A program can also choose to redirect or close its standard input/output and reuse 0
, 1
and 2
.
add a comment |
You can use exec like this at the top of your script:
exec > >(tee "$HOME/somefile.log") 2>&1
For example:
#!/bin/bash -
exec > >(tee "$HOME/somefile.log") 2>&1
echo "$HOME"
echo hi
date
date +%F
echo bye 1>&2
Gives me output to the file $HOME/somefile.log
and to the terminal like this:
/home/saml
hi
Sun Jan 20 13:54:17 EST 2013
2013-01-20
bye
2
Note that this uses bashisms -- it may not work in other shells (e.g., dash). But since the question specified bash, +1.
– Richard Hansen
Jan 21 '13 at 20:39
8
@RichardHansen, process substitution is a feature that was introduced by ksh, not bash and is also supported by zsh so I wouldn't call it a bashism.
– Stéphane Chazelas
Jan 23 '13 at 14:55
6
@StephaneChazelas: You make a good point. I just wanted to point out that the syntax is not supported by the POSIX standard and thus won't universally work in/bin/sh
scripts (many people erroneously use bash syntax in/bin/sh
scripts).
– Richard Hansen
Jan 23 '13 at 16:39
For me this gives/dev/fd/62: Operation not supported
any clues?
– Eun
Jun 2 '15 at 18:18
1
Is there a way to not redirect stderr except to the log file? If the original script ismyscript
and I run./myscript > /dev/null
, I should still seebye
which comes fromecho bye >&2
.
– Martin Jambon
Oct 29 '18 at 17:32
|
show 2 more comments
Write stderr and stdout to a file, display stderr on screen (on stdout)
exec 2> >(tee -a -i "$HOME/somefile.log")
exec >> "$HOME/somefile.log"
Useful for crons, so you can receive errors (and only errors) by mail
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f61931%2fredirect-all-subsequent-commands-stderr-using-exec%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
As for a solution to redirect lots of command at once:
#!/bin/bash
somecommand
somecommand2
somecommand3
2>&1 | tee -a $DEBUGLOG
Why your original solution does not work: exec 2>&1 will redirect the standard error output to the standard output of your shell, which, if you run your script from the console, will be your console. the pipe redirection on commands will only redirect the standart output of the command.
On the point of view of somecommand
, its standard output goes into a pipe connected to tee
and the standard error goes into the same file/pseudofile as the standard error of the shell, which you redirect to the standard output of the shell, which will be the console if you run your program from the console.
The one true way to explain it is to see what really happens:
Your shell's original environment might look like this if you run it from the terminal:
stdin -> /dev/pts/42
stdout -> /dev/pts/42
stderr -> /dev/pts/42
After you redirect standard error into standard output (exec 2>&1
), you ... basically change nothing. But if you redirect the script's standart output to a file, you would end up with an environment like this:
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /dev/pts/42
Then redirecting the shell standard error into standard output would end up like this :
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /your/file
Running a command will inherit this environment. If you run a command and pipe it to tee, the command's environment would be :
stdin -> /dev/pts/42
stdout -> pipe:[4242]
stderr -> /your/file
So your command's standard error still goes into what the shell uses as its standard error.
You can actually see the environment of a command by looking in /proc/[pid]/fd
: use ls -l
to also list the symbolic link's content. The 0
file here is standard input, 1
is standard output and 2
is standard error. If the command opens more files (and most programs do), you will also see them. A program can also choose to redirect or close its standard input/output and reuse 0
, 1
and 2
.
add a comment |
As for a solution to redirect lots of command at once:
#!/bin/bash
somecommand
somecommand2
somecommand3
2>&1 | tee -a $DEBUGLOG
Why your original solution does not work: exec 2>&1 will redirect the standard error output to the standard output of your shell, which, if you run your script from the console, will be your console. the pipe redirection on commands will only redirect the standart output of the command.
On the point of view of somecommand
, its standard output goes into a pipe connected to tee
and the standard error goes into the same file/pseudofile as the standard error of the shell, which you redirect to the standard output of the shell, which will be the console if you run your program from the console.
The one true way to explain it is to see what really happens:
Your shell's original environment might look like this if you run it from the terminal:
stdin -> /dev/pts/42
stdout -> /dev/pts/42
stderr -> /dev/pts/42
After you redirect standard error into standard output (exec 2>&1
), you ... basically change nothing. But if you redirect the script's standart output to a file, you would end up with an environment like this:
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /dev/pts/42
Then redirecting the shell standard error into standard output would end up like this :
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /your/file
Running a command will inherit this environment. If you run a command and pipe it to tee, the command's environment would be :
stdin -> /dev/pts/42
stdout -> pipe:[4242]
stderr -> /your/file
So your command's standard error still goes into what the shell uses as its standard error.
You can actually see the environment of a command by looking in /proc/[pid]/fd
: use ls -l
to also list the symbolic link's content. The 0
file here is standard input, 1
is standard output and 2
is standard error. If the command opens more files (and most programs do), you will also see them. A program can also choose to redirect or close its standard input/output and reuse 0
, 1
and 2
.
add a comment |
As for a solution to redirect lots of command at once:
#!/bin/bash
somecommand
somecommand2
somecommand3
2>&1 | tee -a $DEBUGLOG
Why your original solution does not work: exec 2>&1 will redirect the standard error output to the standard output of your shell, which, if you run your script from the console, will be your console. the pipe redirection on commands will only redirect the standart output of the command.
On the point of view of somecommand
, its standard output goes into a pipe connected to tee
and the standard error goes into the same file/pseudofile as the standard error of the shell, which you redirect to the standard output of the shell, which will be the console if you run your program from the console.
The one true way to explain it is to see what really happens:
Your shell's original environment might look like this if you run it from the terminal:
stdin -> /dev/pts/42
stdout -> /dev/pts/42
stderr -> /dev/pts/42
After you redirect standard error into standard output (exec 2>&1
), you ... basically change nothing. But if you redirect the script's standart output to a file, you would end up with an environment like this:
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /dev/pts/42
Then redirecting the shell standard error into standard output would end up like this :
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /your/file
Running a command will inherit this environment. If you run a command and pipe it to tee, the command's environment would be :
stdin -> /dev/pts/42
stdout -> pipe:[4242]
stderr -> /your/file
So your command's standard error still goes into what the shell uses as its standard error.
You can actually see the environment of a command by looking in /proc/[pid]/fd
: use ls -l
to also list the symbolic link's content. The 0
file here is standard input, 1
is standard output and 2
is standard error. If the command opens more files (and most programs do), you will also see them. A program can also choose to redirect or close its standard input/output and reuse 0
, 1
and 2
.
As for a solution to redirect lots of command at once:
#!/bin/bash
somecommand
somecommand2
somecommand3
2>&1 | tee -a $DEBUGLOG
Why your original solution does not work: exec 2>&1 will redirect the standard error output to the standard output of your shell, which, if you run your script from the console, will be your console. the pipe redirection on commands will only redirect the standart output of the command.
On the point of view of somecommand
, its standard output goes into a pipe connected to tee
and the standard error goes into the same file/pseudofile as the standard error of the shell, which you redirect to the standard output of the shell, which will be the console if you run your program from the console.
The one true way to explain it is to see what really happens:
Your shell's original environment might look like this if you run it from the terminal:
stdin -> /dev/pts/42
stdout -> /dev/pts/42
stderr -> /dev/pts/42
After you redirect standard error into standard output (exec 2>&1
), you ... basically change nothing. But if you redirect the script's standart output to a file, you would end up with an environment like this:
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /dev/pts/42
Then redirecting the shell standard error into standard output would end up like this :
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /your/file
Running a command will inherit this environment. If you run a command and pipe it to tee, the command's environment would be :
stdin -> /dev/pts/42
stdout -> pipe:[4242]
stderr -> /your/file
So your command's standard error still goes into what the shell uses as its standard error.
You can actually see the environment of a command by looking in /proc/[pid]/fd
: use ls -l
to also list the symbolic link's content. The 0
file here is standard input, 1
is standard output and 2
is standard error. If the command opens more files (and most programs do), you will also see them. A program can also choose to redirect or close its standard input/output and reuse 0
, 1
and 2
.
edited Sep 9 '16 at 8:14
Greg Dubicki
15013
15013
answered Jan 20 '13 at 18:16
BatchyXBatchyX
2,4231612
2,4231612
add a comment |
add a comment |
You can use exec like this at the top of your script:
exec > >(tee "$HOME/somefile.log") 2>&1
For example:
#!/bin/bash -
exec > >(tee "$HOME/somefile.log") 2>&1
echo "$HOME"
echo hi
date
date +%F
echo bye 1>&2
Gives me output to the file $HOME/somefile.log
and to the terminal like this:
/home/saml
hi
Sun Jan 20 13:54:17 EST 2013
2013-01-20
bye
2
Note that this uses bashisms -- it may not work in other shells (e.g., dash). But since the question specified bash, +1.
– Richard Hansen
Jan 21 '13 at 20:39
8
@RichardHansen, process substitution is a feature that was introduced by ksh, not bash and is also supported by zsh so I wouldn't call it a bashism.
– Stéphane Chazelas
Jan 23 '13 at 14:55
6
@StephaneChazelas: You make a good point. I just wanted to point out that the syntax is not supported by the POSIX standard and thus won't universally work in/bin/sh
scripts (many people erroneously use bash syntax in/bin/sh
scripts).
– Richard Hansen
Jan 23 '13 at 16:39
For me this gives/dev/fd/62: Operation not supported
any clues?
– Eun
Jun 2 '15 at 18:18
1
Is there a way to not redirect stderr except to the log file? If the original script ismyscript
and I run./myscript > /dev/null
, I should still seebye
which comes fromecho bye >&2
.
– Martin Jambon
Oct 29 '18 at 17:32
|
show 2 more comments
You can use exec like this at the top of your script:
exec > >(tee "$HOME/somefile.log") 2>&1
For example:
#!/bin/bash -
exec > >(tee "$HOME/somefile.log") 2>&1
echo "$HOME"
echo hi
date
date +%F
echo bye 1>&2
Gives me output to the file $HOME/somefile.log
and to the terminal like this:
/home/saml
hi
Sun Jan 20 13:54:17 EST 2013
2013-01-20
bye
2
Note that this uses bashisms -- it may not work in other shells (e.g., dash). But since the question specified bash, +1.
– Richard Hansen
Jan 21 '13 at 20:39
8
@RichardHansen, process substitution is a feature that was introduced by ksh, not bash and is also supported by zsh so I wouldn't call it a bashism.
– Stéphane Chazelas
Jan 23 '13 at 14:55
6
@StephaneChazelas: You make a good point. I just wanted to point out that the syntax is not supported by the POSIX standard and thus won't universally work in/bin/sh
scripts (many people erroneously use bash syntax in/bin/sh
scripts).
– Richard Hansen
Jan 23 '13 at 16:39
For me this gives/dev/fd/62: Operation not supported
any clues?
– Eun
Jun 2 '15 at 18:18
1
Is there a way to not redirect stderr except to the log file? If the original script ismyscript
and I run./myscript > /dev/null
, I should still seebye
which comes fromecho bye >&2
.
– Martin Jambon
Oct 29 '18 at 17:32
|
show 2 more comments
You can use exec like this at the top of your script:
exec > >(tee "$HOME/somefile.log") 2>&1
For example:
#!/bin/bash -
exec > >(tee "$HOME/somefile.log") 2>&1
echo "$HOME"
echo hi
date
date +%F
echo bye 1>&2
Gives me output to the file $HOME/somefile.log
and to the terminal like this:
/home/saml
hi
Sun Jan 20 13:54:17 EST 2013
2013-01-20
bye
You can use exec like this at the top of your script:
exec > >(tee "$HOME/somefile.log") 2>&1
For example:
#!/bin/bash -
exec > >(tee "$HOME/somefile.log") 2>&1
echo "$HOME"
echo hi
date
date +%F
echo bye 1>&2
Gives me output to the file $HOME/somefile.log
and to the terminal like this:
/home/saml
hi
Sun Jan 20 13:54:17 EST 2013
2013-01-20
bye
edited Jan 21 '13 at 15:56
answered Jan 20 '13 at 18:57
slm♦slm
255k71538687
255k71538687
2
Note that this uses bashisms -- it may not work in other shells (e.g., dash). But since the question specified bash, +1.
– Richard Hansen
Jan 21 '13 at 20:39
8
@RichardHansen, process substitution is a feature that was introduced by ksh, not bash and is also supported by zsh so I wouldn't call it a bashism.
– Stéphane Chazelas
Jan 23 '13 at 14:55
6
@StephaneChazelas: You make a good point. I just wanted to point out that the syntax is not supported by the POSIX standard and thus won't universally work in/bin/sh
scripts (many people erroneously use bash syntax in/bin/sh
scripts).
– Richard Hansen
Jan 23 '13 at 16:39
For me this gives/dev/fd/62: Operation not supported
any clues?
– Eun
Jun 2 '15 at 18:18
1
Is there a way to not redirect stderr except to the log file? If the original script ismyscript
and I run./myscript > /dev/null
, I should still seebye
which comes fromecho bye >&2
.
– Martin Jambon
Oct 29 '18 at 17:32
|
show 2 more comments
2
Note that this uses bashisms -- it may not work in other shells (e.g., dash). But since the question specified bash, +1.
– Richard Hansen
Jan 21 '13 at 20:39
8
@RichardHansen, process substitution is a feature that was introduced by ksh, not bash and is also supported by zsh so I wouldn't call it a bashism.
– Stéphane Chazelas
Jan 23 '13 at 14:55
6
@StephaneChazelas: You make a good point. I just wanted to point out that the syntax is not supported by the POSIX standard and thus won't universally work in/bin/sh
scripts (many people erroneously use bash syntax in/bin/sh
scripts).
– Richard Hansen
Jan 23 '13 at 16:39
For me this gives/dev/fd/62: Operation not supported
any clues?
– Eun
Jun 2 '15 at 18:18
1
Is there a way to not redirect stderr except to the log file? If the original script ismyscript
and I run./myscript > /dev/null
, I should still seebye
which comes fromecho bye >&2
.
– Martin Jambon
Oct 29 '18 at 17:32
2
2
Note that this uses bashisms -- it may not work in other shells (e.g., dash). But since the question specified bash, +1.
– Richard Hansen
Jan 21 '13 at 20:39
Note that this uses bashisms -- it may not work in other shells (e.g., dash). But since the question specified bash, +1.
– Richard Hansen
Jan 21 '13 at 20:39
8
8
@RichardHansen, process substitution is a feature that was introduced by ksh, not bash and is also supported by zsh so I wouldn't call it a bashism.
– Stéphane Chazelas
Jan 23 '13 at 14:55
@RichardHansen, process substitution is a feature that was introduced by ksh, not bash and is also supported by zsh so I wouldn't call it a bashism.
– Stéphane Chazelas
Jan 23 '13 at 14:55
6
6
@StephaneChazelas: You make a good point. I just wanted to point out that the syntax is not supported by the POSIX standard and thus won't universally work in
/bin/sh
scripts (many people erroneously use bash syntax in /bin/sh
scripts).– Richard Hansen
Jan 23 '13 at 16:39
@StephaneChazelas: You make a good point. I just wanted to point out that the syntax is not supported by the POSIX standard and thus won't universally work in
/bin/sh
scripts (many people erroneously use bash syntax in /bin/sh
scripts).– Richard Hansen
Jan 23 '13 at 16:39
For me this gives
/dev/fd/62: Operation not supported
any clues?– Eun
Jun 2 '15 at 18:18
For me this gives
/dev/fd/62: Operation not supported
any clues?– Eun
Jun 2 '15 at 18:18
1
1
Is there a way to not redirect stderr except to the log file? If the original script is
myscript
and I run ./myscript > /dev/null
, I should still see bye
which comes from echo bye >&2
.– Martin Jambon
Oct 29 '18 at 17:32
Is there a way to not redirect stderr except to the log file? If the original script is
myscript
and I run ./myscript > /dev/null
, I should still see bye
which comes from echo bye >&2
.– Martin Jambon
Oct 29 '18 at 17:32
|
show 2 more comments
Write stderr and stdout to a file, display stderr on screen (on stdout)
exec 2> >(tee -a -i "$HOME/somefile.log")
exec >> "$HOME/somefile.log"
Useful for crons, so you can receive errors (and only errors) by mail
add a comment |
Write stderr and stdout to a file, display stderr on screen (on stdout)
exec 2> >(tee -a -i "$HOME/somefile.log")
exec >> "$HOME/somefile.log"
Useful for crons, so you can receive errors (and only errors) by mail
add a comment |
Write stderr and stdout to a file, display stderr on screen (on stdout)
exec 2> >(tee -a -i "$HOME/somefile.log")
exec >> "$HOME/somefile.log"
Useful for crons, so you can receive errors (and only errors) by mail
Write stderr and stdout to a file, display stderr on screen (on stdout)
exec 2> >(tee -a -i "$HOME/somefile.log")
exec >> "$HOME/somefile.log"
Useful for crons, so you can receive errors (and only errors) by mail
edited Mar 4 at 17:09
answered Mar 1 at 11:53
LluísLluís
505513
505513
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f61931%2fredirect-all-subsequent-commands-stderr-using-exec%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
In some shells,
|&
works as a shortcut for2>&1 |
, it's at least slightly more convenient.– Kevin
Jan 20 '13 at 18:12