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

[Jack Kamm <jackkamm@gmail.com>]

Hi,

Nick Dokos <ndokos@gmail.com> writes:

>> That said, we have three solutions:
>>
>> 1. Stick to a strict reading of Org and bash manuals: the absence of a
>>    :results header means "return the value, i.e. the exit status".
>>
>> 2. Deviate from this strict reading, introduce an exception for *all*
>>    shell blocks: no :results header means "return output" and you need
>>    to use :results value to get the exit status (your proposal).
>>
>> 3. Deviate from this strict reading and introduce an option that says:
>>    "Don't deviate from the Org's and bash manuals for all src blocks".
>>
>> Obviously, nobody wants the first solution.
>
> I'm not convinced of that: personally, I would be happy with the first
> solution and maybe others would be too.
> 
> My longer term suggestion (which, I realize, does not help to close
> *this* case any time soon):
> 
> I think that the global default setting `:results value' is wrong

Strongly agree with Nick on both points here. I prefer option 1 over
options 2 and 3, I think it is the more consistent and simple behavior.

I also think ":results value" is a problematic default.

Anecdotally, I use Org-Babel as a computational notebook similar to
Jupyter or Rmarkdown, and set ":session :results output" for nearly all
my org-babel blocks.

Of course, there are many ways in which org-babel can be used, and for
some uses, ":results value" is the better default. But for other use
cases, including shell blocks, ":results output" is the more intuitive
default.

And I think this is really the problem here. The result of a shell block
is surprising to the new user, because the user probably wants ":results
output", but ":results value" is the default. I'm not sure of the
solution to this problem, but I don't think it's to change the meaning
of ":results value".