Re: Bug or not a bug? dot expansion in ob-shell

[Derek Feichtinger <derek.feichtinger@psi.ch>]

+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 <theophilusx@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 <ndokos@gmail.com> writes:
>
>> Hi Bastien,
>>
>> Bastien <bzg@gnu.org> writes:
>>
>>> Hi Diego,
>>>
>>> Diego Zamboni <diego@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.feichtinger@psi.ch
Building/Room No. WHGA/U126
Forschungsstrasse 111
CH-5232 Villigen PSI