From: Eric Schulte <schulte.eric@gmail.com>
To: Michael Brand <michael.ch.brand@gmail.com>
Cc: "András Major" <andras.g.major@gmail.com>,
"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com>,
"Achim Gratz" <stromeko@nexgo.de>,
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: Tue, 23 Aug 2011 11:13:53 -0600 [thread overview]
Message-ID: <8762lodoy1.fsf@gmail.com> (raw)
In-Reply-To: CALn3zoh6rKeRSrtF3MXJqzWbbuGELnhC1rZv=CzmQSDr80nbyg@mail.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/
next prev parent reply other threads:[~2011-08-23 17:21 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
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 [this message]
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=8762lodoy1.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=andras.g.major@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=michael.ch.brand@gmail.com \
--cc=stromeko@nexgo.de \
--cc=wxhgmqzgwmuf@spammotel.com \
/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).