emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tom Gillespie <tgbugs@gmail.com>
To: Jack Kamm <jackkamm@gmail.com>
Cc: Bastien <bzg@gnu.org>, Nick Dokos <ndokos@gmail.com>,
	emacs-orgmode@gnu.org
Subject: Re: Bug or not a bug? dot expansion in ob-shell
Date: Sat, 29 Feb 2020 18:08:23 -0800	[thread overview]
Message-ID: <CA+G3_POpw2nCzrvauAAMUkpw__jfzXfvceUcJ0+AKg3Je7GCVQ@mail.gmail.com> (raw)
In-Reply-To: <87y2sltnas.fsf@gmail.com>

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 <jackkamm@gmail.com> 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.
>

  reply	other threads:[~2020-03-01  2:08 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19  9:02 Bug or not a bug? dot expansion in ob-shell Vladimir Nikishkin
2020-02-19  9:27 ` Fraga, Eric
2020-02-19  9:41   ` Bastien
2020-02-19  9:43     ` Bastien
2020-02-19  9:57       ` Bastien
2020-02-19 11:03     ` Fraga, Eric
2020-02-19 11:38       ` Bastien
2020-02-19 11:56         ` Fraga, Eric
2020-02-19 12:06           ` Vladimir Nikishkin
2020-02-19 12:10           ` Bastien
2020-02-19 12:27             ` Bastien
2020-02-27 14:25             ` Kaushal Modi
2020-02-19 12:47           ` Tim Cross
2020-02-19 13:00             ` Bastien
2020-02-19 13:15               ` Tim Cross
2020-02-19 13:23                 ` Bastien
2020-02-19 13:31               ` Fraga, Eric
2020-02-19 13:43                 ` Bastien
2020-02-19 14:05                   ` Fraga, Eric
2020-02-19 16:00                     ` Bastien
2020-02-19 19:43                       ` Diego Zamboni
2020-02-19 20:41                         ` Samuel Wales
2020-02-19 21:32                         ` Bastien
2020-02-20 20:37                           ` Nick Dokos
2020-02-20 21:01                             ` Tim Cross
2020-02-21  6:55                               ` Derek Feichtinger
2020-02-21  8:04                             ` Bastien
2020-02-21 21:04                               ` Nick Dokos
2020-02-22  6:23                                 ` Jack Kamm
2020-02-22 13:37                                 ` Bastien
2020-02-23  9:50                                   ` Stefan Nobis
2020-02-23 13:13                                     ` Bastien
2020-02-23 16:13                                     ` Jack Kamm
2020-02-23 20:44                                       ` Bastien
2020-02-29 15:35                                   ` Jack Kamm
2020-02-29 15:39                                     ` Jack Kamm
2020-03-01  2:08                                       ` Tom Gillespie [this message]
2020-03-01  3:50                                         ` Tim Cross
2020-03-04 18:41                                           ` Nick Dokos
2020-09-06 17:33                                           ` Bastien
2020-03-01  4:09                                         ` Jack Kamm
2020-03-01  5:07                                           ` Tom Gillespie
2020-03-01  5:58                                             ` Jack Kamm
2020-03-01 15:46                                               ` Jack Kamm
2020-09-06 17:36                                                 ` Bastien
2020-09-07 17:39                                                   ` Bastien
2020-02-23 15:27                               ` Fraga, Eric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+G3_POpw2nCzrvauAAMUkpw__jfzXfvceUcJ0+AKg3Je7GCVQ@mail.gmail.com \
    --to=tgbugs@gmail.com \
    --cc=bzg@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=jackkamm@gmail.com \
    --cc=ndokos@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).