[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Orgmode] Re: [Babel] No output returned if just one command is failing
From: |
Sébastien Vauban |
Subject: |
[Orgmode] Re: [Babel] No output returned if just one command is failing |
Date: |
Thu, 02 Dec 2010 16:43:59 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (windows-nt) |
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