help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-bash] stdout and stderr to two different process substitutions


From: Greg Wooledge
Subject: Re: [Help-bash] stdout and stderr to two different process substitutions
Date: Wed, 25 Jan 2012 09:48:46 -0500
User-agent: Mutt/1.4.2.3i

On Wed, Jan 25, 2012 at 08:36:22AM -0600, Peng Yu wrote:
> > Test case:
> >  $ { echo STDOUT ; echo STDERR 1>&2 ;} > >(gzip > xx.gz) 2> >(tee yy 1>&2)
> 
> It is a little unclear to me how "tee yy 1>&2" works here.

I'd rewrite it slightly to reduce the amount of punctuation being thrown
at me in a single line:

foo() {
  echo STDOUT
  echo STDERR 1>&2
}
foo > >(gzip > xx.gz) 2> >(tee yy 1>&2)

That's the same as Bob's example, just reformatted a bit.

> If I just call "tee yy", nothing will be printed to stdout. "STDERR"
> comes from stdin. How come "1>&2" redirect stdin to stderr? Thanks!

First of all, 1>&2 literally does mean "redirect stdin to where stderr is
currently pointing".  That's what it's for.

Second of all, "just calling tee yy" means it's waiting for you to type
something.  If you type a line and press Enter, it will write a copy to
stdout (the terminal), and another copy to the file yy.

I'll ignore the "STDERR comes from stdin" part, since that makes no sense.

With all that said, here's an analysis of the foo > ... 2> ... line:

The process substitutions are, I believe, handled first.  Each of these
is a background process, inheriting the shell's FDs.

So, first we create a background process, gzip, with its stdout redirected
to xx.gz.  Its stdin will come from a special pipe.

Second, we create a background proecss, tee, with its stdout redirected to
the place its stderr is going -- which is the stderr inherited from the
shell, or "the screen".  Tee's stdin will be from another special pipe.
It will also copy its input to the file named "yy".

Third, the shell's redirections are processed left to right.  The first
redirection is "> Something", which changes where foo's stdout goes.
The second redirection is "2> Something", which changes where foo's
stderr goes.

So in the end, what we have is a command foo, whose stdout is going to
special pipe A, and whose stderr is going to special pipe B.  Special
pipe A leads to gzip, whose stdout goes to the file xx.gz.  Special pipe
B leads to tee, which writes a copy of the piped input to the file yy,
and another copy of the piped input to the screen (foo's stderr).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]