+1 - I also think that this is the correct behavior, and that the average user's expectations can be best fulfilled by making ":results output" the default. Adding the option will make it more difficult to share code blocks and documents.
Best regards, Derek On Thu, Feb 20 2020, Tim Cross <theophil...@gmail.com> wrote: > +1 - this is basically my feeling as well. I've spent the last couple of > days thinking about the additional option suggestion, but something just > didn't feel right to me. I think Nick has hit the nail on the head. > > Adding the additional option seems to be making things more confusing. > The basic idea that result value is what the block returns i.e. the > return value of the last statement for shell blocks and result output is > what the code in the block sends to stdout/stderr. This seems the most > intuitive to me. > > > Nick Dokos <ndo...@gmail.com> writes: > >> Hi Bastien, >> >> Bastien <b...@gnu.org> writes: >> >>> Hi Diego, >>> >>> Diego Zamboni <di...@zzamboni.org> writes: >>> >>>> I'm late to the discussion so I apologize in advance, but this fix >>>> seems counterintuitive to me. In my mind, for any shell code: >>>> >>>> - Return value: exit code of the last command >>>> - Output: whatever the commands print >>> >>> Yes, that's what is *now* possible if you set >>> ob-shell-return-value-is-exit-status to t. >>> >>> Unless I miss something, it was not possible before today. >>> >>> #+begin_src shell >>> echo Hello! >>> #+end_src >>> >>> would simply return "Hello!" as a return. >>> >>> No exit code was *never* output. >>> >>>> So to me, it's intuitive that =:exports value= would return the exit >>>> code of the last command, and =:exports output= would produce the >>>> output of the commands. I don't understand why a new option is >>>> needed. >>> >>> ... because it was not the case before. Or maybe *I* miss something. >>> >>> Can you show me something that was working before and that is not >>> anymore? >>> >>> Thanks, >> >> I welcome the fix but not the option: the option situation in Org mode >> was pretty horrible, then ca 2010, you did a survey and some options >> were eliminated (not sure about the year or whether it *was* you who >> did the survey, but I'm pretty sure there was one): that was the right >> direction to go, but it wasn't enough. Org mode needs to be put into >> an option diet, so adding another one here (and a rather gratuitous >> one in my view) is not the way to go. >> >> `:results value' should *always* produce the value of the last expression, >> which for shell programs is the exit status of the last command. >> >> `:results output' should *always* produce all of the output of the program. >> >> An argument can be made that `:results value' is the default, but it >> is the less useful option for shell programs. So maybe for shell >> blocks, make the default to be `:results output' instead: people get >> what they always got before the fix without lifting a finger, the exit status >> is now available with `:results value', and the option can go away >> quietly and quickly, before it becomes another contributor to the Org >> mode technical debt. -- Paul Scherrer Institut Dr. Derek Feichtinger Phone: +41 56 310 47 33 Group Head HPC and Emerging Technologies Email: derek.feichtin...@psi.ch Building/Room No. WHGA/U126 Forschungsstrasse 111 CH-5232 Villigen PSI