How to store standard error in a variable

Question

Let\'s say I have a script like the following:

useless.sh

echo \"This Is Error\" 1>&2
echo \"This Is Output\" 

And I have an

Answer 1

For the benefit of the reader, this recipe here

• can be re-used as oneliner to catch stderr into a variable
• still gives access to the return code of the command
• Sacrifices a temporary file descriptor 3 (which can be changed by you of course)
• And does not expose this temporary file descriptors to the inner command

If you want to catch stderr of some command into var you can do

{ var="$( { command; } 2>&1 1>&3 3>&- )"; } 3>&1;

Afterwards you have it all:

echo "command gives $? and stderr '$var'";

If command is simple (not something like a | b) you can leave the inner {} away:

{ var="$(command 2>&1 1>&3 3>&-)"; } 3>&1;

Wrapped into an easy reusable bash-function (probably needs version 3 and above for local -n):

: catch-stderr var cmd [args..]
catch-stderr() { local -n v="$1"; shift && { v="$("$@" 2>&1 1>&3 3>&-)"; } 3>&1; }

Explained:

• local -n aliases "$1" (which is the variable for catch-stderr)
• 3>&1 uses file descriptor 3 to save there stdout points
• { command; } (or "$@") then executes the command within the output capturing $(..)
• Please note that the exact order is important here (doing it the wrong way shuffles the file descriptors wrongly):
  • 2>&1 redirects stderr to the output capturing $(..)
  • 1>&3 redirects stdout away from the output capturing $(..) back to the "outer" stdout which was saved in file descriptor 3. Note that stderr still refers to where FD 1 pointed before: To the output capturing $(..)
  • 3>&- then closes the file descriptor 3 as it is no more needed, such that command does not suddenly has some unknown open file descriptor showing up. Note that the outer shell still has FD 3 open, but command will not see it.
  • The latter is important, because some programs like lvm complain about unexpected file descriptors. And lvm complains to stderr - just what we are going to capture!

You can catch any other file descriptor with this recipe, if you adapt accordingly. Except file descriptor 1 of course (here the redirection logic would be wrong, but for file descriptor 1 you can just use var=$(command) as usual).

Note that this sacrifices file descriptor 3. If you happen to need that file descriptor, feel free to change the number. But be aware, that some shells (from the 1980s) might understand 99>&1 as argument 9 followed by 9>&1 (this is no problem for bash).

Also note that it is not particluar easy to make this FD 3 configurable through a variable. This makes things very unreadable:

: catch-var-from-fd-by-fd variable fd-to-catch fd-to-sacrifice command [args..]
catch-var-from-fd-by-fd()
{
local -n v="$1";
local fd1="$2" fd2="$3";
shift 3 || return;

eval exec "$fd2>&1";
v="$(eval '"$@"' "$fd1>&1" "1>&$fd2" "$fd2>&-")";
eval exec "$fd2>&-";
}

Security note: The first 3 arguments to catch-var-from-fd-by-fd must not be taken from a 3rd party. Always give them explicitly in a "static" fashion.

So no-no-no catch-var-from-fd-by-fd $var $fda $fdb $command, never do this!

If you happen to pass in a variable variable name, at least do it as follows: local -n var="$var"; catch-var-from-fd-by-fd var 3 5 $command

This still will not protect you against every exploit, but at least helps to detect and avoid common scripting errors.

Notes:

• catch-var-from-fd-by-fd var 2 3 cmd.. is the same as catch-stderr var cmd..
• shift || return is just some way to prevent ugly errors in case you forget to give the correct number of arguments. Perhaps terminating the shell would be another way (but this makes it hard to test from commandline).
• The routine was written such, that it is more easy to understand. One can rewrite the function such that it does not need exec, but then it gets really ugly.
• This routine can be rewritten for non-bash as well such that there is no need for local -n. However then you cannot use local variables and it gets extremely ugly!
• Also note that the evals are used in a safe fashion. Usually eval is considerered dangerous. However in this case it is no more evil than using "$@" (to execute arbitrary commands). However please be sure to use the exact and correct quoting as shown here (else it becomes very very dangerous).