Hi, Nick Dokos <ndo...@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".
