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

András Major <andras.g.major@gmail.com> writes:

> Hi Eric,
>
>> If we did return the value of shell scripts then ":results value" would
>> almost always simply return 0 (or possibly an error message).  For this
>> reason shell code blocks do not implement value returns, but rather will
>> always collect results from STDOUT.
>
> I think that this unnecessarily throws away potentially useful
> functionality.  Example: I want to fill a table with data such that
> the value of a cell depends on whether a file (whose path is specified
> by another cell, for instance) exists or not.  This would be most
> easily done using an sh block which returns a numeric exit code.  I
> don't see a reason for making clandestine exceptions to the rules in
> the manual and strongly suggest that the output and value options be
> honoured for every language.
>

I do see your point, and I agree that consistent behavior between
languages is of paramount importance.  In fact I began working on
implementing the return of error codes from shell code blocks, however I
ran into the following issue.

For every language, when an error is thrown babel tries to open an error
buffer holding the contents of the error message.  This is very useful
for debugging code which lives inside of a code block -- a process which
can otherwise be difficult because of the extra layer of indirection
babel interposes between the programmer and the codes execution.  In
order to return exit codes from shell blocks babel would have to
silently ignore errors in shell blocks.  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.

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.

>
> In order not to break existing Org files, I would suggest that the
> default choice between value and output (when not explicitly
> specified) depend on the language.  With this functionality, sh code
> blocks that don't specify ":results output" will still work as they
> did before.
>

I agree, if we go this route this is the way to do it.

Best -- Eric

>
>   András
>
>
>

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