Bastien writes:
> At first, I thought "If ':results value' is always the same as the
> default, why have ':results value' at all?" and thought it'd be an
> argument for having different defaults for different languages but
> I see how I was wrong: expectations for defaults should be stable,
>
Hi Jack,
Jack Kamm writes:
> I think it's a bad idea that ":results value", and not specifying
> ":results", give different behavior.
Indeed.
At first, I thought "If ':results value' is always the same as the
default, why have ':results value' at all?" and thought it'd be an
argument for
Hi Tim,
sorry for the late reply, and thanks a lot for the clear summary.
Tim Cross writes:
> It seems to me that two separate issues have been mixed up and causing
> some confusion here. However, I think it is actually quite simple once
> we consider the issues separately.
>
> Issue 1:
Hi Tim,
Tim Cross writes:
> It seems to me that two separate issues have been mixed up and causing
> some confusion here. However, I think it is actually quite simple once
> we consider the issues separately.
>
> Issue 1: Defining the meaning of :result value and :result output
> Issue 2:
As someone who doesn't really use ob-shell, I've made too much noise in
this thread, and am intending this to be my last comment here...
I think it's a bad idea that ":results value", and not specifying
":results", give different behavior.
In my own Org-babel files, I usually have a header line
Hi Tom,
Tom Gillespie writes:
> As with many things in emacs, I sometimes feel like I'm loosing my
> mind, or loosing track of just exactly what variables are set
You're not losing your mind. After some further testing I find that
you're right, and my understanding of the situation was
Hi Jack,
As with many things in emacs, I sometimes feel like I'm loosing my
mind, or loosing track of just exactly what variables are set or not
set, but I could swear that for at least the past year when running
#+begin_src bash blocks with C-c C-c and no :results header set the
results are
Hi Tom,
Tom Gillespie writes:
> 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.
Wasn't option 1 already the default behavior, until the changes
It seems to me that two separate issues have been mixed up and causing
some confusion here. However, I think it is actually quite simple once
we consider the issues separately.
Issue 1: Defining the meaning of :result value and :result output
Issue 2: Specifying what the default :result setting
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
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
Hi Bastien,
Bastien writes:
> thanks for your thoughtful inputs. I've now removed the option.
I think it's good you removed the option.
However, it looks like the behavior now is to return the output, instead
of the exit code, when ":results value".
According to my reading of this thread,
Hello all,
On Wed, Feb 19, 2020 at 7:11 AM Bastien wrote:
> Hi Eric,
>
> note that the previous behavior only _seemed_ right by chance: there
> is no notion of getting the exit code of the shell command in
> ob-shell.el, and returning "0" is just a hazard here, just because
>
Hi Jack,
Jack Kamm writes:
> Stefan Nobis writes:
>
>> What about a third collection option 'none' and make this the default?
>
> A variant on this idea, would be to instead have the third collection
> option be 'default', which would stand for a language-specific
> default. For example,
Hi Stefan,
Stefan Nobis writes:
> What about a third collection option 'none' and make this the default?
A variant on this idea, would be to instead have the third collection
option be 'default', which would stand for a language-specific
default. For example, ":results default" could be
On Friday, 21 Feb 2020 at 09:04, Bastien wrote:
[...]
> 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".
[...]
> Obviously, nobody wants the first solution.
Hi Stefan,
Stefan Nobis writes:
> The downside would be that many existing Org documents needs to be
> fixed (but maybe it would be not too hard to automate the adjustments)
> and some source blocks may become a little more verbose.
Yes, backward-compatibilities issues, verbosity, and a
Bastien writes:
> I agree we should have a discussion on whether :results value is a
> good default.
What about a third collection option 'none' and make this the default?
This would emphasize that there is no sensible default for all babel
languages, users and use cases. Users would be forced
Hi Nick and Jack,
thanks for your thoughtful inputs. I've now removed the option.
I agree we should have a discussion on whether :results value is a
good default. But I think this needs previous work on documenting
what is the actual behavior of the main Babel libraries wrt "value"
vs
Hi,
Nick Dokos 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*
>>
Hi Bastien,
I think all this is reasonable. I have some inline comments and
a suggestion at the end.
Bastien writes:
> Hi Nick,
>
> I didn't conduct the survey in 2013, you can find the results here:
> https://orgmode.org/worg/org-configs/org-customization-survey.html
>
> I understand why you
Hi Nick,
I didn't conduct the survey in 2013, you can find the results here:
https://orgmode.org/worg/org-configs/org-customization-survey.html
I understand why you (and Tim and Derek) think an option is too much.
But let's separate two problems: one is that Org have many options,
some perhaps
+1 - I also think that this is the correct behavior, and that the
average user's expectations can be best fulfilled by making ":results output"
the default. Adding the option will make it more difficult to share code
blocks and documents.
Best regards,
Derek
On Thu, Feb 20 2020, Tim Cross
+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
Hi Bastien,
Bastien writes:
> Hi Diego,
>
> Diego Zamboni 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
Hi Diego,
Diego Zamboni 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
to stir the pot:
speaking for myself, i only wanted the output, and never the error
mechanism, and my attempts to get output reliably ended up in my
habitually putting in every shell block this boilerplate:
===
{
the code i actually want
} 2>&1
:
===
--
The Kafka Pandemic
What is misopathy?
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
So to me, it's intuitive that =:exports value= would return the exit code
of the
I've implemented the suggestion I made in master:
New option ~ob-shell-return-value-is-exit-status~
When set to =t=, consider the return value of a shell source code
block is the exit status of its last command.
The default for this option is =nil=, i.e. the return value of a
On Wednesday, 19 Feb 2020 at 14:43, Bastien wrote:
> Note that currently (9.3) we have this:
[...]
> ... so the default today is not even to consider "the last command",
> but the output of all commands.
Maybe, if you wish to get version 9.4 out, the best approach would be to
fix that one
Hi Eric,
"Fraga, Eric" writes:
> On Wednesday, 19 Feb 2020 at 14:00, Bastien wrote:
>> Anyway, I don't have yet a clue on how to add this new option. I'll
>> leave it to Eric first (if he has time) then look at it later this
>> week.
>
> Time is an issue (middle of teaching term). More
On Wednesday, 19 Feb 2020 at 14:00, Bastien wrote:
> Anyway, I don't have yet a clue on how to add this new option. I'll
> leave it to Eric first (if he has time) then look at it later this
> week.
Time is an issue (middle of teaching term). More importantly, my
elisp-fu is not necessarily up
Hi Tim,
Tim Cross writes:
> I'm not sure - need to think about it some more and go back through the
> manual. My initial feeling is that the example block you show should
> only return "Hello!" when you request output as the reuslts and
> otherwise return the return value of echo (which is the
Hi Bastien,
I'm not sure - need to think about it some more and go back through the
manual. My initial feeling is that the example block you show should
only return "Hello!" when you request output as the reuslts and
otherwise return the return value of echo (which is the exit code in
this case).
Hi Tim,
thanks for your proposal. I think we agree here.
My suggestion is to have a new option ob-shell-value-is-exit-status.
When set to nil (the default), the "return value" of a shell source
block would be the output of the last command. This is the current
behavior where we have e.g.
I think I agree with Eric here. However, perhaps I don't fully
understand all the details.
Many shell commans, especially those
which mainly perform 'side effects' like echo, return the exit code.
This value is often used in shell scripts as a type of short hand/short
circuit i.e. combined with
Bastien writes:
> Then we need to fix ob-shell.el to return the exit code of the last
> command when :results is not set or explicitely set to "value". Is
> this something you want to look at?
>
> Maybe by adding a "echo $?" instruction at the end of shell blocks
> or by wrapping the code into
Hi Eric,
note that the previous behavior only _seemed_ right by chance: there
is no notion of getting the exit code of the shell command in
ob-shell.el, and returning "0" is just a hazard here, just because
(org-babel--string-to-number ".") returns "0", while it should return
nil.
"Fraga, Eric"
That's an excellent response, Eric!
Now what about this block:
#+begin_src shell
printf "%s" '
(computer . ?type)
exit'
#+end_src
ср, 19 февр. 2020 г. в 19:56, Fraga, Eric :
> On Wednesday, 19 Feb 2020 at 12:38, Bastien wrote:
> > "0" is the _exit code_ of the successful echo command,
On Wednesday, 19 Feb 2020 at 12:38, Bastien wrote:
> "0" is the _exit code_ of the successful echo command, not the value
> returned by the echo command.
But echo does not "return" the string as a value. It outputs the
string.
To quote the man page for bash, "the return value of a simple
Hi Eric,
"Fraga, Eric" writes:
> On Wednesday, 19 Feb 2020 at 10:41, Bastien wrote:
>> It returned "0" for me, while I guess "." is expected.
>
> I expected 0 as that is the "value" (i.e. the status in a shell) of
> the last command.
Quoting the manual:
‘value’
Default. Functional mode.
On Wednesday, 19 Feb 2020 at 10:41, Bastien wrote:
> It returned "0" for me, while I guess "." is expected.
I expected 0 as that is the "value" (i.e. the status in a shell) of the
last command. If you want ".", I would expect one to use :results
output in the src block header?
--
: Eric S
Bastien writes:
> PS: Ouch, I broke a few tests. I'm looking at this right now.
Those have been fix, together with org-babel--string-to-number,
which should not allow "1 2" to be interpreted as a number.
Eric, if my reading of the expected output does not match yours
please let me know.
--
Bastien writes:
> Let me know if it does the right thing for you.
PS: Ouch, I broke a few tests. I'm looking at this right now.
--
Bastien
Hi Eric and Vladimir,
"Fraga, Eric" writes:
> On Wednesday, 19 Feb 2020 at 17:02, Vladimir Nikishkin wrote:
>> Could you check if the following block behaves as expected?
>
> It does for me. What did you expect and what did you get?
It returned "0" for me, while I guess "." is expected.
The
On Wednesday, 19 Feb 2020 at 17:02, Vladimir Nikishkin wrote:
> Could you check if the following block behaves as expected?
It does for me. What did you expect and what did you get?
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-316-g5dd772
46 matches
Mail list logo
