capturing stderr to variable.

capturing stderr to variable.

[Ray Andrews]

Gentlemen:

'highlight' seems to have no return value. If you feed it a file who's 
type it does not recognize, it sends a message to stderr. To create a 
test for that, I'm doing this:

    $ highlight $filename 2> /tmp/highlight_err
    [ -s "/tmp/highlight_err" ] &&
    echo="Highlighting is active, but the file is not recognized."
    rm /tmp/highlight_err > /dev/null

... which is clumsy.  Researching it, I find that there's no simple way 
to redirect stderr to a variable, or to some other way of capturing the 
error condition. Suggestions involve things like:

     ... 2>&4 1>&3; } 2>&1 )

... which I'd not use anyway for clarity's sake.  Any suggestions?  I 
was wondering, since redirection and piping are (I believe) at about the 
same level of parsing, one might suppose that " ... 2| " would be 
legal.  That is to say that we could sent stderr to a command as well as 
to a file.

Re: capturing stderr to variable.

[Mikael Magnusson]

On Sat, Nov 14, 2015 at 5:18 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> Gentlemen:
>
> 'highlight' seems to have no return value. If you feed it a file who's type
> it does not recognize, it sends a message to stderr. To create a test for
> that, I'm doing this:
>
>    $ highlight $filename 2> /tmp/highlight_err
>    [ -s "/tmp/highlight_err" ] &&
>    echo="Highlighting is active, but the file is not recognized."
>    rm /tmp/highlight_err > /dev/null
>
> ... which is clumsy.  Researching it, I find that there's no simple way to
> redirect stderr to a variable, or to some other way of capturing the error
> condition. Suggestions involve things like:
>
>     ... 2>&4 1>&3; } 2>&1 )
>
> ... which I'd not use anyway for clarity's sake.  Any suggestions?  I was
> wondering, since redirection and piping are (I believe) at about the same
> level of parsing, one might suppose that " ... 2| " would be legal.  That is
> to say that we could sent stderr to a command as well as to a file.

foo 2> >(bar)

-- 
Mikael Magnusson

Re: capturing stderr to variable.

[Bart Schaefer]

On Nov 14,  7:56am, Mikael Magnusson wrote:
}
} On Sat, Nov 14, 2015 at 5:18 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
} >
} > wondering, since redirection and piping are (I believe) at about the
} > same level of parsing, one might suppose that " ... 2| " would be
} > legal. That is to say that we could sent stderr to a command as well
} > as to a file.
} 
} foo 2> >(bar)

That doesn't really help very much, though, because >(bar) runs in a
separate process so the original shell can't do anything interesting
with the captured output.

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:

    % >file echo this goes to file
    % echo this >>file also goes to file

Whereas "|" ends the command and begins the next.

So, pipes work only on stdout, and to redirect stderr to a pipe you
must first use 2>&1 to copy stderr to stdout ... which means even if
you think it's unclear, you must first separately redirect stdout in
order to pipe only stderr.

E.g.
	{ 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).

-- 
Barton E. Schaefer

Re: capturing stderr to variable.

[Ray Andrews]

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 ...

Re: capturing stderr to variable.

[Ray Andrews]

On 11/14/2015 09:20 AM, Ray Andrews wrote:
>
>
>>     { 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)
>>
>>
>
>
And it's even simpler in case the output is to be captured and not 
echoed to stdout at all:

     body_list=( ${(@f)"$( highlight $filename )"} ) 2>&1 | read _err

If I do:

     body_list=( ${(@f)"$( highlight $filename > /dev/tty )"} ) 2>&1 | 
read _err

... I get the output to screen, so that answers my previous question.  
The syntactic logic might be harder than Finnish, but it *is* there.

Re: capturing stderr to variable.

[Bart Schaefer]

On Nov 14,  9:20am, Ray Andrews wrote:
}
} > 	{ highlight ... >/dev/tty } 2>&1 | read highlight_err
} >
} 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.

It's equivalent to opening the same file twice.
 
} Speaking of obscurites, have you given any thought to that cloning of 
} the environment thing I mentioned a while  back?

I'd have to see the entire output of "set" rather than just the result
of grepping it.  (And it'd be preferable that you not post that to the
list ...)

Re: capturing stderr to variable.

[Ray Andrews]

On 11/14/2015 11:02 AM, Bart Schaefer wrote:
> On Nov 14,  9:20am, Ray Andrews wrote:
> }
> } > 	{ highlight ... >/dev/tty } 2>&1 | read highlight_err
> } >
> } 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.
>
> It's equivalent to opening the same file twice.
>   
> } Speaking of obscurites, have you given any thought to that cloning of
> } the environment thing I mentioned a while  back?
>
> I'd have to see the entire output of "set" rather than just the result
> of grepping it.  (And it'd be preferable that you not post that to the
> list ...)
>
Ok, if you want to pursue it I'll send it privately.