Re: Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]

[Eric Schulte <schulte.eric@gmail.com>]

Michael Brand <michael.ch.brand@gmail.com> writes:

> Hi Eric
>
> 2011/8/20 Eric Schulte <schulte.eric@gmail.com>:
>> [...] I would lean towards thinking
>> that passing along error messages is more important than returning error
>> codes, but if the community thinks differently I'm happy to change the
>> ob-sh behavior.
>
> A non-zero exit status and stderr of a process are not necessarily
> related. Because a process may also use
> - a non-zero exit status without error situation (e. g. grep, diff)
> - stderr for output not related with errors
> - stdout for error messages
> I would like very much to be able to collect all available feedback
> from a process at the same run. Even with an optional indication of
> the origin, for ambiguity like the "hello" below or just for clarification.
>

I agree that some mechanism for collecting output from STDERR could be
useful, however its implementation would not be trivial.

>
>> Unfortunately it seems that in either case the sh code blocks will need
>> to be different than other languages either in its handling of errors or
>> of return values.  This is unavoidable due to the overloading of return
>> values in the shell as error indicators.
>
> If the shell is a special case for babel anyway, why not something
> like the following?
>
> #+begin_src sh :exports stdout stderr exit_status -v
>   echo hello
>   echo hello >&2
>   false
> #+end_src
>
> #+results:
> : 2: hello
> : 1: hello
> : exit status: 1
>
> This would have been
> - with an option -v for verbosity to prefix
>   stdout with "1: ", stderr with "2: " and the exit status
> - with the exit status of the last command without the need of an
>   extra "echo $?".
>
> My habit as a background info: To learn more from the shell I use
> - a shell prompt with the exit status of the last command
> - when I sometimes want to visually divide stdout and stderr (bash):
>   { { echo hello; echo hello >&2; } 3>&1 1>&2 2>&3 | sed 's/^/2: /'; } \
>       3>&1 1>&2 2>&3 | sed 's/^/1: /'; 3>&-
>   to output:
>   2: hello
>   1: hello
>

I think that in general mixing the output status with STDOUT would not
be a clean solution, as it would require parsing to use.  Also, I don't
think that the example above would help to bring the behavior of sh code
blocks more in-line with other code blocks.

Note that during interactive evaluation if the exit status is non-0 then
STDERR will be dumped into a babel error buffer which will be poped up,
so this information will not be silently discarded.

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/