From: Vladimir Nikishkin <lockywolf@gmail.com>
To: Bastien <bzg@gnu.org>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: org-babel opens the error output of a block in a separate window... unless :stdin is given, but how are they connected?
Date: Thu, 10 Sep 2020 16:54:21 +0800 [thread overview]
Message-ID: <CA+A2iZYjmf9jY8HcqsAbiBRk6f6e=P=+yHdt69==cMv_kX=2zQ@mail.gmail.com> (raw)
In-Reply-To: <877dt6ryud.fsf@gnu.org>
I don't know how to debug this.
The *Org-Babel Error Output* emerges when the control flow returns
from the following sexp:
(org-babel-execute-src-block
current-prefix-arg (org-babel-get-src-block-info nil context))
It is line 17862 in the org.el
I do not understand what causes its appearance, because while the
execution continues inside the org-babel-execute-src-block, no
expression creates this buffer. I don't know "what" to instrument to
debug this behaviour.
>The example above does not work for me. Can you provide another one?
I do have another example that is "almost" the same and does not
involve chibi-scheme.
```
# -*- mode:org; -*-
#+name: empty
#+begin_quote
1
#+end_quote
#+begin_src shell :stdin empty
printf "test\n" 1>&2
#+end_src
```
Compare the evaluation of the second block with and without the ":stdin empty".
On my machine, if no ":stdin empty" is present, the block produces no
output when C-c'd (which, I guess, is expected), since the output is
empty.
However, add ":stdin empty". The line ": test" magically appears after
the #+RESULTS: , although I suspect that it shouldn't, as "test" is
printed to the standard error, not standard output.
Apparently, adding ":stdin" somehow magically switches org from "print
code's standard output in the #+results and process errors as if they
are errors in a separate buffer if the return value is not 0" to "just
print whatever the program prints on the console, regardless of
whether it is standard output or standard error after the #+results:
line".
Hope this helps.
Added later:
I actually found that the way the script is evaluated is totally
different in the presence and in the absence of :stdin.
The line 213 of ob-shell.el checks for "(or stdin cmdline)", and the
evaluation goes into two independent routes, and does not even get
evaluated with org-babel-eval.
(org-babel-eval) is the actual function that creates the error window,
and if :stdin is not given, control flow doesn't even use this
function.
So my question, perhaps, would be "would it be possible to modify
org-babel-sh-evaluate" so that only one function be used for code
evaluation? Perhaps the one that is used with the (or stdin cmdline)
route, as it seems more functional (and can be forced by setting
:stdin to an empty block name).
Vlad
On Mon, 7 Sep 2020 at 12:32, Bastien <bzg@gnu.org> wrote:
>
> Hi Vladimir,
>
> Vladimir Nikishkin <lockywolf@gmail.com> writes:
>
> > #+name: empty
> > #+begin_quote
> >
> > 1
> > #+end_quote
> >
> > #+begin_src shell :shebang "#! /usr/bin/chibi-scheme :stdin empty
> > (/ 1 0)
> > #+end_src
>
> The example above does not work for me. Can you provide another one?
>
> > Now the chibi-scheme shebang is just an example of an app writing
> > things to stderr. The actual content of the <<empty>> doesn't matter,
> > the app errs before ever having a chance to read anything from stdin.
> >
> > However, when :stdin is given (as in the MWE), the resulting error
> > output is printed in the :RESULTS , and if not, it is displayed in a
> > separate (a bit annoying) window called "*Org-Babel Error Output*.
> >
> > I would like to ask how these two things, stdin, and stderr are
> > connected. Perhaps, this is a bug?
>
> I don't know but perhaps you can instrument the relevant functions in
> ob-shell.el and see what going on, if you still have this issue?
>
> Thanks,
>
> --
> Bastien
--
Yours sincerely, Vladimir Nikishkin
prev parent reply other threads:[~2020-09-10 8:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-25 1:36 org-babel opens the error output of a block in a separate window... unless :stdin is given, but how are they connected? Vladimir Nikishkin
2020-09-07 4:32 ` Bastien
2020-09-10 8:54 ` Vladimir Nikishkin [this message]
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+A2iZYjmf9jY8HcqsAbiBRk6f6e=P=+yHdt69==cMv_kX=2zQ@mail.gmail.com' \
--to=lockywolf@gmail.com \
--cc=bzg@gnu.org \
--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).