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

[Tim Cross]

+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 <address@hidden> writes:

> Hi Bastien,
>
> Bastien <address@hidden> writes:
>
>> Hi Diego,
>>
>> Diego Zamboni <address@hidden> 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.


--
Tim Cross