Re: [Babel] No output returned if just one command is failing

From: "Sébastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: [Babel] No output returned if just one command is failing
Date: Thu, 02 Dec 2010 16:43:59 +0100	[thread overview]
Message-ID: <80d3pkuqm8.fsf@missioncriticalit.com> (raw)
In-Reply-To: 87d3pkialo.fsf@gmail.com

Hi Eric and Dan,

Dan Davison wrote:
> Sébastien Vauban wrote:
>> "Eric Schulte" wrote:
>>> I don't forsee adding partial results insertion both because
>>>
>>> - it would add a good deal of complexity to the code to insert results
>>>   part-way through a run
>>
>> I can't comment on this, of course.
>>
>>> - the current behavior of only inserting results on a fully successful run
>>>   is reasonable and is probably more obvious (at least to me) than
>>>   inserting partial results
>>
>> Being fond of Babel, I'm using it always, everywhere. I prefer:
>>
>> 1. typing my shell commands in an Org buffer,
>> 2. evaluate the block,
>> 3. get the results automagically inserted in the buffer,
>> 4. (eventually, version the whole file for later comparisons when updating
>>    the code),
>> 5. export the whole to HTML and/or PDF.
>>
>> The current behavior, even if totally respectable and defendable, inhibits
>> such a way of working: if you write (or update) a shell code, and don't see
>> (more or less) the same things as the ones you would see in a shell buffer,
>> then you can't use such an Org buffer -- as long as one command fails.
>>
>> I don't especially want you to change your position, but I'm explaining the
>> "negative" consequences for me.
>
> I definitely have some sympathy with your request. On two occasions I've had
> to manually make this change just to carry on working.
>
> But do we actually change babel in this direction? [...]
>
> The thing is that babel currently has a clear, simple, rule which says: if
> there's an error, the result is the elisp value nil.
>
> Eric and I have discussed in the past whether there should be any change
> in this direction. The idea of a :debug header arg has been floated,
> that would allow this behavior. Or tacking stdout on to the error
> output. I tend to think that the behavior you request does need to be
> made available, somehow, whether by default or not.

If find this conclusion a bit contradictory with the fact that you even needed
it yourself. I'm not talking of having this by default, but somehow possible.
But, I know, we (you) have to ensure everything stays coherent, and somehow
simple...

BTW, what's the internal "definition" (in Org Babel) of "unsuccessful run" of
a (sh) command block?

Is it "return code != 0"?

If yes, such a sh block would never produce any results when the machine is
not a known name (as first command would "fail"):

#+begin_src sh :var machine :results output
ping $machine
rc=$?
if [ $rc == 0 ]; then
    echo "Machine pinged successfully with its name...";
else
    echo "Trying to ping machine by its IP...";
    ipmachine=$(grep whichever-list.txt | cut -f 2);
    ping $ipmachine
fi
#+end_src

(the above is just a simply sample of code which includes tests of rc)

Though, it does currently work with both known and unknown machines. So I'm
clearly missing something here.

Best regards,
  Seb

PS- I already sent this (the last paragraphs) hours ago. It did not reach the
    ML. Is it a Gmane problem?  Or something else (Gnus)?

-- 
Sébastien Vauban

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode