Re: capturing stderr to variable.

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 11/14/2015 12:01 AM, Bart Schaefer wrote:
> The shell language doesn't define a digit preceding a "|" symbol as a
> redirection because "|" separates commands whereas ">" modifies the
> single current command.  The difference makes more sense if you are
> aware that redirections can appear anywhere:

Thanks, lucid as always.  Yeah, the two things might be parsed at the 
same level, but they are not symmetrical with each other.


> 	{ highlight ... >/dev/tty } 2>&1 | read highlight_err
> 	# now $highlight_err has the first line of stderr
> 	# (this does not work in most shells other than zsh)
>
> Note that without the braces, 2>&1 combines stdout and stderr so
> both go to /dev/tty and "read" either has no input or reads from
> the terminal (depending on whether the "multios" option is set).
Well that sure beats some of the solutions I found on the net.  The only 
think obscure there is why redirecting stdout to where it's going anyway 
does anything.

Speaking of obscurites, have you given any thought to that cloning of 
the environment thing I mentioned a while  back?  Of course it's 
impossible for the same variable to exist several times in the 
environment, nevertheless 'set' was reporting exactly that, it seems.  
It sounds significant.


Then seeing what's going on:

   $ set | grep "aArchive"

   A=/aArchive
   A=/aArchive
   A=/aArchive
   A=/aArchive
   A=/aArchive

... that's impossible, however ...