From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Bug or not a bug? dot expansion in ob-shell
Date: Fri, 21 Feb 2020 08:01:11 +1100 [thread overview]
Message-ID: <87sgj5dld4.fsf@gmail.com> (raw)
In-Reply-To: <877e0h571l.fsf@alphaville.usersys.redhat.com>
+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 <ndokos@gmail.com> writes:
> Hi Bastien,
>
> Bastien <bzg@gnu.org> writes:
>
>> Hi Diego,
>>
>> Diego Zamboni <diego@zzamboni.org> 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
next prev parent reply other threads:[~2020-02-20 21:01 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 [this message]
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
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=87sgj5dld4.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).