9584
Comment: "command shift" is better than "shift", but still no guarantee it will return false (busybox), and buggy shells may still exit fatally (older mksh, pdksh).
|
6378
syntax hl
|
Deletions are marked like this. | Additions are marked like this. |
Line 7: | Line 7: |
{{{ output=$(command) # stdout only; stderr remains uncaptured output=$(command 2>&1) # both stdout and stderr will be captured |
{{{#!highlight bash output=$(command) # stdout only; stderr remains uncaptured output=$(command 2>&1) # both stdout and stderr will be captured |
Line 14: | Line 14: |
{{{ command status=$? |
{{{#!highlight bash command status=$? |
Line 21: | Line 21: |
{{{ output=$(command) status=$? |
{{{#!highlight bash output=$(command) status=$? |
Line 29: | Line 29: |
{{{ if command; then echo "it succeeded" else echo "it failed" fi |
{{{#!highlight bash if command; then printf "it succeeded\n" else printf "it failed\n" fi |
Line 39: | Line 39: |
{{{ if output=$(command); then echo "it succeeded" |
{{{#!highlight bash if output=$(command); then printf "it succeeded\n" |
Line 47: | Line 47: |
{{{ grep foo somelogfile | head -5 status=${PIPESTATUS[0]} |
{{{#!highlight bash grep foo somelogfile | head -5 status=${PIPESTATUS[0]} |
Line 54: | Line 54: |
{{{ set -o pipefail if ! grep foo somelogfile | head -5; then echo "uh oh" fi |
{{{#!highlight bash set -o pipefail if ! grep foo somelogfile | head -5; then printf "uh oh\n" fi |
Line 63: | Line 63: |
{{{ output=$(command 2>&1 >/dev/null) # Save stderr, discard stdout. output=$(command 2>&1 >/dev/tty) # Save stderr, send stdout to the terminal. output=$(command 3>&2 2>&1 1>&3-) # Save stderr, send stdout to script's stderr. |
{{{#!highlight bash output=$(command 2>&1 >/dev/null) # Save stderr, discard stdout. output=$(command 2>&1 >/dev/tty) # Save stderr, send stdout to the terminal. output=$(command 3>&2 2>&1 1>&3-) # Save stderr, send stdout to script's stderr. |
Line 69: | Line 69: |
Since the last example may seem a bit confusing, here is the explanation. First, keep in mind that `1>&3-` is equivalent to `1>&3 3>&-`. So it will be easier to analyse the following sequence: | Since the last example may seem a bit confusing, here is the explanation. First, keep in mind that `1>&3-` is equivalent to `1>&3 3>&-`. So it will be easier to analyse the following sequence: `$(... 3>&2 2>&1 1>&3 3>&-)` |
Line 71: | Line 71: |
`3>&2 2>&1 1>&3 3>&-` 1. Let's assume this is run in a terminal, so stdin, stdout and stderr are all initially connected to the terminal (tty). || fd 0 (stdin) || fd 1 (stdout) || fd 2 (stderr) || || /dev/tty || /dev/tty || /dev/tty || 1. `$(...)`: First, the command substitution is set up. Command's stdout ([[FileDescriptor]] 1) gets captured (by using a pipe internally). Command's stderr (FD 2) still points to its regular place (the script's stderr). || fd 0 (stdin) || fd 1 (stdout) || fd 2 (stderr) || || /dev/tty || pipe || /dev/tty || 1. `3>&2`: Next, FD 3 should point to what FD 2 points to at this very moment, meaning FD 3 will point to the script's stderr ("save stderr in FD 3"). || fd 0 (stdin) || fd 1 (stdout) || fd 2 (stderr) || fd 3 || || /dev/tty || pipe || /dev/tty || /dev/tty || 1. `2>&1`: Next, FD 2 should point to what FD 1 currently points to, meaning FD 2 will point to stdout. Right now, both FD 2 and FD 1 would be captured. || fd 0 (stdin) || fd 1 (stdout) || fd 2 (stderr) || fd 3 || || /dev/tty || pipe || pipe || /dev/tty || 1. `1>&3`: Next, FD 1 should point to what FD 3 currently points to, meaning FD 1 will point to the script's stderr. FD 1 is no longer captured. We have "swapped" FD 1 and FD 2. || fd 0 (stdin) || fd 1 (stdout) || fd 2 (stderr) || fd 3 || || /dev/tty || /dev/tty || pipe || /dev/tty || 1. `3>&-`: Finally, we close FD 3 as it is no longer necessary. || fd 0 (stdin) || fd 1 (stdout) || fd 2 (stderr) || || /dev/tty || /dev/tty || pipe || |
|| Redirection || fd 0 (stdin) || fd 1 (stdout) || fd 2 (stderr) || fd 3 || Description || || initial || /dev/tty || /dev/tty || /dev/tty || || Let's assume this is run in a terminal, so stdin, stdout and stderr are all initially connected to the terminal (tty). || || `$(...)` || /dev/tty || '''pipe''' || /dev/tty || || First, the command substitution is set up. Command's stdout ([[FileDescriptor]] 1) gets captured (by using a pipe internally). Command's stderr (FD 2) still points to its regular place (the script's stderr). || || `3>&2` || /dev/tty || pipe || /dev/tty || '''/dev/tty'''|| Next, FD 3 should point to what FD 2 points to at this very moment, meaning FD 3 will point to the script's stderr ("save stderr in FD 3"). || || `2>&1` || /dev/tty || pipe || '''pipe''' || /dev/tty || Next, FD 2 should point to what FD 1 currently points to, meaning FD 2 will point to stdout. Right now, both FD 2 and FD 1 would be captured. || || `1>&3` || /dev/tty || '''/dev/tty'''|| pipe || /dev/tty || Next, FD 1 should point to what FD 3 currently points to, meaning FD 1 will point to the script's stderr. FD 1 is no longer captured. We have "swapped" FD 1 and FD 2. || || `3>&-` || /dev/tty || /dev/tty || pipe || || Finally, we close FD 3 as it is no longer necessary. || |
Line 98: | Line 85: |
{{{ exec 3>&1 # Save the place that stdout (1) points to. output=$(command 2>&1 1>&3) # Run command. stderr is captured. exec 3>&- # Close FD #3. |
{{{#!highlight bash exec 3>&1 # Save the place that stdout (1) points to. output=$(command 2>&1 1>&3) # Run command. stderr is captured. exec 3>&- # Close FD #3. |
Line 103: | Line 90: |
# Or this alternative, which captures stderr, letting stdout through: { output=$(command 2>&1 1>&3-) ;} 3>&1 |
# Or this alternative, which captures stderr, letting stdout through: { output=$(command 2>&1 1>&3-) ;} 3>&1 |
Line 112: | Line 99: |
{{{ result=$( { stdout=$(cmd) ; } 2>&1; echo "this line is the separator"; echo "$stdout") var_out=${result#*this line is the separator$'\n'} var_err=${result%$'\n'this line is the separator*} |
{{{#!highlight bash result=$( { stdout=$(cmd) ; } 2>&1 printf "this line is the separator\n" printf "%s\n" "$stdout" ) var_out=${result#*this line is the separator$'\n'} var_err=${result%$'\n'this line is the separator*} |
Line 120: | Line 111: |
{{{ cmd() { curl -s -v http://www.google.fr; } |
{{{#!highlight bash cmd() { curl -s -v http://www.google.fr; } |
Line 123: | Line 114: |
result=$( { stdout=$(cmd); returncode=$?; } 2>&1; echo -n "this is the separator"; echo "$stdout"; exit $returncode) returncode=$? |
result=$( { stdout=$(cmd); returncode=$?; } 2>&1 printf "this is the separator" printf "%s\n" "$stdout" exit "$returncode" ) returncode=$? |
Line 126: | Line 122: |
var_out=${result#*this is the separator} var_err=${result%this is the separator*} |
var_out=${result#*this is the separator} var_err=${result%this is the separator*} |
Line 133: | Line 129: |
Please find below my contribution to capture stdout and stderr in two separate variables using only FD redirections.<<BR>> All my apologizes if I place it at the wrong place.<<BR>> Code tested with GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)<<BR>> You can send me feedback at this address: <<MailTo(jpm4bashfaq AT gmx DOT fr)>> {{{ # A simple function to send a message on stdout and another one on stderr foo () { echo "message on stdout"; echo "message on stderr" >&2 return 42 } }}} {{{ # Function capturing stdout and stderr in two separate variables using only FD redirections. foo2 () { { # Code block purpose is to unset these variables and to display unset diagnostic on screen unset stdout stderr return_code declare -p stdout stderr return_code } source <( { { { stdout="$(foo)" # Call your command here: I put foo as an example } 2>&1 return_code="$?" declare -p stdout >&2 declare -p return_code >&2 } | { stderr="$(cat)" declare -p stderr >&2 } } 2>&1 ) declare -p stdout stderr return_code } }}} Sample session: {{{ user@domain:~$ foo2 bash: declare: stdout: not found bash: declare: stderr: not found bash: declare: return_code: not found declare -- stdout="message on stdout" declare -- stderr="message on stderr" declare -- return_code="42" user@domain:~$ }}} Better function based on foo2: {{{ # Execute a command and store stdout and stderr in two separate variables using only FD redirections # # $1: variable name to store stdout command output # $2: variable name to store stderr command output # $3: variable name to store command return code # $4: command to execute # $5: first command argument # ... # $n: last command argument execute_and_store_std_out_err() { local p_stdout=$1 local p_stderr=$2 local p_return_code=$3 [[ $p_stdout != stdout && -n $p_stdout && $p_stderr != stderr && -n $p_stderr && $p_return_code != return_code && -n $p_return_code ]] || return shift 3 source <( { { { stdout=$("$@") } 2>&1 return_code=$? declare -p stdout return_code >&2 } | { stderr=$(</dev/fd/0) declare -p stderr >&2 } } 2>&1 ) eval "${p_stdout}"'="${stdout}"' && eval "${p_stderr}"'="${stderr}"' && eval "${p_return_code}"'="${return_code}"' } }}} Sample session: {{{ user@domain:~$ unset out err ret ; declare -p out err ret ; execute_and_store_std_out_err out err ret foo ; declare -p out err ret bash: declare: out: not found bash: declare: err: not found bash: declare: ret: not found declare -- out="message on stdout" declare -- err="message on stderr" declare -- ret="42" user@domain:~$ }}} End of <<MailTo(jpm4bashfaq AT gmx DOT fr)>> contribution. ---- |
How can I store the return value and/or output of a command in a variable?
Well, that depends on whether you want to store the command's output (either stdout, or stdout + stderr) or its exit status (0 to 255, with 0 typically meaning "success").
If you want to capture the output, you use command substitution:
If you want the exit status, you use the special parameter $? after running the command:
If you want both:
The assignment to output has no effect on command's exit status, which is still in $?.
If you don't actually want to store the exit status, but simply want to take an action upon success or failure, just use if:
Or if you want to capture stdout as well as taking action on success/failure, without explicitly storing or checking $?:
What if you want the exit status of one command from a pipeline? If you want the last command's status, no problem -- it's in $? just like before. If you want some other command's status, use the PIPESTATUS array (BASH only). Say you want the exit status of grep in the following:
Bash 3.0 added a pipefail option as well, which can be used if you simply want to take action upon failure of the grep:
Now, some trickier stuff. Let's say you want only the stderr, but not stdout. Well, then first you have to decide where you do want stdout to go:
Since the last example may seem a bit confusing, here is the explanation. First, keep in mind that 1>&3- is equivalent to 1>&3 3>&-. So it will be easier to analyse the following sequence: $(... 3>&2 2>&1 1>&3 3>&-)
Redirection |
fd 0 (stdin) |
fd 1 (stdout) |
fd 2 (stderr) |
fd 3 |
Description |
initial |
/dev/tty |
/dev/tty |
/dev/tty |
|
Let's assume this is run in a terminal, so stdin, stdout and stderr are all initially connected to the terminal (tty). |
$(...) |
/dev/tty |
pipe |
/dev/tty |
|
First, the command substitution is set up. Command's stdout (FileDescriptor 1) gets captured (by using a pipe internally). Command's stderr (FD 2) still points to its regular place (the script's stderr). |
3>&2 |
/dev/tty |
pipe |
/dev/tty |
/dev/tty |
Next, FD 3 should point to what FD 2 points to at this very moment, meaning FD 3 will point to the script's stderr ("save stderr in FD 3"). |
2>&1 |
/dev/tty |
pipe |
pipe |
/dev/tty |
Next, FD 2 should point to what FD 1 currently points to, meaning FD 2 will point to stdout. Right now, both FD 2 and FD 1 would be captured. |
1>&3 |
/dev/tty |
/dev/tty |
pipe |
/dev/tty |
Next, FD 1 should point to what FD 3 currently points to, meaning FD 1 will point to the script's stderr. FD 1 is no longer captured. We have "swapped" FD 1 and FD 2. |
3>&- |
/dev/tty |
/dev/tty |
pipe |
|
Finally, we close FD 3 as it is no longer necessary. |
A little note: operation n>&m- is sometimes called moving FD m to FD n.
This way what the script writes to FD 2 (normally stderr) will be written to stdout because of the second redirection. What the script writes to FD 1 (normally stdout) will be written to stderr because of the first and third redirections. Stdout and stderr got replaced. Done.
It's possible, although considerably harder, to let stdout "fall through" to wherever it would've gone if there hadn't been any redirection. This involves "saving" the current value of stdout, so that it can be used inside the command substitution:
In the last example above, note that 1>&3- duplicates FD 3 and stores a copy in FD 1, and then closes FD 3. It could also be written 1>&3 3>&-.
What you cannot do is capture stdout in one variable, and stderr in another, using only FD redirections. You must use a temporary file (or a named pipe) to achieve that one.
Well, you can use a horrible hack like:
Obviously, this is not robust, because either the standard output or the standard error of the command could contain whatever separator string you employ.
And if you want the exit code of your cmd (here a modification in the case of if the cmd stdout nothing)
Note: the original question read, "How can I store the return value of a command in a variable?" This was, verbatim, an actual question asked in #bash, ambiguity and all.