CODEWITHSUNDEEP
linuxbash
pdm
pdm

Reputation: 1107

Bash: multiple redirection

Early in a script, I see this:

exec 3>&2

And later:

{ $app $conf_file &>$app_log_file & } 1>&3 2>&1

My understanding of this looks something like this:

Isn't that some kind of circular madness? 3>stderr>stdout>3>etc?

I'm especially concerned as to the intention/implications of this line because I'd like to start running some apps using this script with valgrind. I'd like to see valgrind's output interspersed with the app's log statements, so I'm hoping that the default output of stderr is captured by the confusing line above. However, in some of the crashes that have led me to wanting to use valgrind, I've seen glibc errors outputted straight to the terminal, rather than captured in the app's log file.

So, the question(s): What does that execution line do, exactly? Does it capture stderr? If so, why do I see glibc output on the command line when an app crashes? If not, how should I change it to accomplish this goal?

Upvotes: 8

Views: 7506

Answers (3)

Logan Lee
Logan Lee

Reputation: 1007

You need a context first, as in @Peter Cordes example. He provided the context by setting >stdout and 2>stderr first.

I have modified his example a bit.

$ bash -c 'exec 3>&2; { sleep 60m & } 1>&3 2>&1'  >stdout 2>stderr
$ ps aux | grep sleep
logan     272163  0.0  0.0   8084   580 pts/2    S    19:22   0:00 sleep 60m
logan     272165  0.0  0.0   8912   712 pts/2    S+   19:23   0:00 grep --color=auto sleep
$ ll /proc/272163/fd
total 0
dr-x------ 2 logan logan  0 Aug 25 19:23 ./
dr-xr-xr-x 9 logan logan  0 Aug 25 19:23 ../
lr-x------ 1 logan logan 64 Aug 25 19:23 0 -> /dev/null
l-wx------ 1 logan logan 64 Aug 25 19:23 1 -> /tmp/tmp.Vld71a451u/stderr
l-wx------ 1 logan logan 64 Aug 25 19:23 2 -> /tmp/tmp.Vld71a451u/stderr
l-wx------ 1 logan logan 64 Aug 25 19:23 3 -> /tmp/tmp.Vld71a451u/stderr

First, exec 3>&2 sets fd3 to point to stderr file. Then 1>&3 sets fd1 to point to stderr file also. Lastly, 2>&1 sets fd2 to point to stderr file too! (don't get confused with stderr fd2 and in this case stderr just being a random file name)

The reason fd0 is set to /dev/null, I'm guessing, is because the command is run in a non-interactive shell.

Upvotes: 0

Peter Cordes
Peter Cordes

Reputation: 366094

Ok, well let's see what happens in practice:

peter@tesla:/tmp/test$ bash -c 'exec 3>&2; { sleep 60m &>logfile & } 1>&3 2>&1'  > stdout 2>stderr
peter@tesla:/tmp/test$ psg sleep
peter    22147  0.0  0.0   7232   836 pts/14   S    15:51   0:00 sleep 60m
peter@tesla:/tmp/test$ ll /proc/22147/fd
total 0
lr-x------ 1 peter peter 64 Jul  8 15:51 0 -> /dev/null
l-wx------ 1 peter peter 64 Jul  8 15:51 1 -> /tmp/test/logfile
l-wx------ 1 peter peter 64 Jul  8 15:51 2 -> /tmp/test/logfile
l-wx------ 1 peter peter 64 Jul  8 15:51 3 -> /tmp/test/stderr

I'm not sure exactly why the author of your script ended up with that line of code. Presumably it made sense to them when they wrote it. The redirections outside the curly braces happen before the redirections inside, so they're both overriden by the &>logfile. Even errors from bash, like command not found would end up in the logfile.

You say you see glibc messages on your terminal when the app crashes. I think your app must be using fd 3 after it starts. i.e., it was written to be started from a script that opened fd 3 for it, or else it opens /dev/tty or something.

BTW, psg is a function I define in my .bashrc:
psg(){ ps aux | grep "${@:-$USER}" | grep -v grep; }
recently updated to: 

psg(){  local pids=$(pgrep -f "${@:--u$USER}"); [[ $pids ]] && ps u   -p $pids; }
psgw(){ local pids=$(pgrep -f "${@:--u$USER}"); [[ $pids ]] && ps uww -p $pids; }

Upvotes: 2

Etan Reisner
Etan Reisner

Reputation: 81052

You misread the 3>&2 syntax. It means open fd 3 and make it a duplicate of fd 2. See Duplicating File Descriptors.

In the same way 2>&1 does not mean make fd 2 point to the location of fd 1 it means re-open fd 2 as a duplicate of fd 1 (mostly the same net effect but different semantics).

Also remember that all redirections occur as they happen and that there are no "pointers" here. So 2>&1 1>/dev/null does not redirect standard error to /dev/null it leaves standard error attached to wherever standard output had been attached to (probably the terminal).

So the code in question does this:

  1. Open fd 3 as a duplicate of fd 2
  2. Re-open fd 1 as a duplicate of fd 3
  3. Re-open fd 2 as a duplicate of fd 1

Effectively those lines send everything to standard error (or wherever fd 2 was attached when the initial exec line ran). If the redirections had been 2>&1 1>&3 then they would have swapped locations. I wonder if that was the original intention of that line since, as written, it is fairly pointless.

Not to mention that with the redirection inside the brace list the redirections on the outside of the brace list are fairly useless.

Upvotes: 6

Related Questions