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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode