Hi Eric
On Tue, Aug 23, 2011 at 19:13, Eric Schulte wrote:
> 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.
Thanks for emphasizing this. I did
Michael Brand writes:
> Hi Eric
>
> 2011/8/20 Eric Schulte :
>> [...] 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 a
Achim Gratz writes:
> Michael Brand writes:
>> If the shell is a special case for babel anyway, why not something
>> like the following?
>
> Ehm, no. But I think that it would be generally useful (not just for
> shell blocks) to be able to capture stderr, either together with stdout
> or separa
Michael Brand writes:
> If the shell is a special case for babel anyway, why not something
> like the following?
Ehm, no. But I think that it would be generally useful (not just for
shell blocks) to be able to capture stderr, either together with stdout
or separately into a result target block a
Hi Eric
2011/8/20 Eric Schulte :
> [...] 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 neces
András Major 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
Hi Achim,
Achim Gratz wrote:
> András Major writes:
>> This would be most easily done using an sh block which returns a
>> numeric exit code.
>
> No one keeps you from using
>
> echo $?
>
> in the last line of that shell block.
Even if this is a smart workaround, it don't think this is equivalen
Hi András and Eric,
András Major wrote:
>
>> 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
András Major writes:
> This would be most easily done using an sh block which returns a
> numeric exit code.
No one keeps you from using
echo $?
in the last line of that shell block.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the T
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 unnecessa
Andras Major writes:
> Hello, here is an example of apparently erroneous behaviour of the
> :results switch. In this example, we use an sh block, but it also
> appears to affect other languages (will need more investigation).
>
> Example Org code:
>
> #+begin_src sh :exports output
> echo "Hel
Hello, here is an example of apparently erroneous behaviour of the
:results switch. In this example, we use an sh block, but it also
appears to affect other languages (will need more investigation).
Example Org code:
#+begin_src sh :exports output
echo "Hello World 1"
#+end_src
#+results:
: H
12 matches
Mail list logo
