emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: org-babel opens the error output of a block in a separate window...


From: Vladimir Nikishkin
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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]