[CLUE-Tech] bash: overwrite and redirect

[marcus hall]

On Tue, Feb 18, 2003 at 10:17:41AM -0600, Michael J. Hammel wrote:
> On Tue, 2003-02-18 at 10:57, marcus hall wrote:
> > Careful about the order..  There is a subtle ordering to when each
> > argument is processed.  The above will first dup stdout to stderr,
> > *then* point stdout to result_file.  So, stderr will be going to
> > the old destination of stdout and only stdout will be going to the
> > file.  You really need to say:
> > 
> > some command > result_file 2>&1
> 
> Argggh.  I'm starting to hate bash.  I may switch back to ksh.  At least
> on FreeBSD the order is correct - I use it all the time there, like so:
> 
>   make blah 2>&1 | tee make.out
> 
> This has the desired effect of redirecting stderr to stdout and then
> piping stdout to "tee" under FreeBSD using bash.  If this does not work
> under Linux, then consistancy does not seem to be the order of the day
> for that shell. 

Well, it actually has the effect of piping stdout to "tee" *and*then*
redirecting stderr to stdout, that way they both go to "tee".  This
is the same for bash, ksh, and just about all shells derived from
the original bourne shell (csh and its derivitives are slightly
different).  In fact, that is what I was talking about in the snipped
part of my original message..

The general rule is that the shell builds the pipeline first, then
for each command in the pipeline, the arguments are processed left
to right.  The earlier posting suggested "some command 2>&1 >result_file"
which would first redirect stderr to the original stdout, *then*
redirect stdout to the file (process arguments left to right), when
what was wanted was "some command >result_file 2>&1" which would
redirect stdout to the file, *then* redirect stderr to stdout (which
is now going to the file).

marcus hall
marcus at tuells.org