From: Eric Schulte <schulte.eric@gmail.com>
To: "András Major" <andras.g.major@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Date: Fri, 19 Aug 2011 16:46:34 -0600 [thread overview]
Message-ID: <87pqjybpg7.fsf@gmail.com> (raw)
In-Reply-To: loom.20110819T204348-795@post.gmane.org
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/
next prev parent reply other threads:[~2011-08-21 18:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-19 6:36 Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)] Andras Major
2011-08-19 13:33 ` Eric Schulte
2011-08-19 18:52 ` András Major
2011-08-19 19:03 ` Achim Gratz
2011-08-19 19:38 ` Sebastien Vauban
2011-08-19 19:20 ` Sebastien Vauban
2011-08-19 22:46 ` Eric Schulte [this message]
2011-08-22 21:49 ` Michael Brand
2011-08-23 16:18 ` Achim Gratz
2011-08-23 17:10 ` Eric Schulte
2011-08-23 17:13 ` Eric Schulte
2011-08-29 19:17 ` Michael Brand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pqjybpg7.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=andras.g.major@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).