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

[Tom Gillespie]

Hi all,
    Sorry to be late to this thread (and for a wall of text), but as a
heavy user of ob-shell I wanted to chime in. First a disclosure, I
would be very unhappy if option 1 were selected, it would require me
to make a whole bunch of changes and try to find an option to revert
to the current default behavior. When I run a bash block in org mode,
I want what is going to stdout, why else would I run it in org? If I
don't want to capture the output then it is either in a pipeline
inside the block, or I will silence the results. Option two is by far
the most reasonable answer in my opinion and there is a consistent
principle which can be applied in many cases so that it would not be
an exception. The principle is that block defaults for results should
default to the value that the language itself makes the most
accessible. Shell return codes are esoteric from this point of view, I
had been writing bash scripts for years before I learned about $?. By
far the most actionable and accessible thing to a user of a shell
program is the stdout -- ignore the naming for a moment, because the
meaning is not in the name, it is in how it interacts with other
programs in the larger environment. If we apply the logic that says
that option 1 should be the default, then python blocks set to results
value should return nothing unless an error is raised and then they
should return the error. This is clearly absurd, no python programmer
cares about the absence of an error and making the default behavior of
python blocks verbosely report their non-errorness by default would
likely incite a riot. What has happened with shells is that the
nomenclature has been switched with respect to how users and other
code consume and deal with 'outputs' aka return values in any other
langues, shell return values are error signals and should be treated
as such, unfortunately (or perhaps fortunately?) org-mode doesn't have
an error handling/signaling system, but if a python code block fails
emacs will yell at us, shells don't do this, it is up to the user to
detect and handle the error case themselves, but that is a language
internal matter. In summary, option 2 seems to me to be the most
consistent with how users interact with shell commands and shell
scripts, return codes are more akin to error handling in other
languages, so ignoring the naming issues, if `my-org-block` behave
like a shell function, then pipe would be the more appropriate default
behavior than `$?`. I think that the underlying principle can be
applied to other languages as well to arrive at sane defaults.
Thoughts?
Tom


On Sat, Feb 29, 2020 at 7:41 AM Jack Kamm <address@hidden> wrote:
>
> Sorry, I was confused about this:
>
> > According to my reading of this thread, most of the commenters were in
> > agreement that we should keep the original behavior and return the exit
> > code, as we do in 9.3.
>
> Actually, it looks like ":results value" does return the exit code. I
> just got confused because shell blocks now return the output when no
> ":results" is specified.
>