From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id WFe6CefpWV8nTQAA0tVLHw (envelope-from ) for ; Thu, 10 Sep 2020 08:55:03 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id cCGHBefpWV+VNQAA1q6Kng (envelope-from ) for ; Thu, 10 Sep 2020 08:55:03 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3E3109404D2 for ; Thu, 10 Sep 2020 08:55:02 +0000 (UTC) Received: from localhost ([::1]:53174 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGIM7-0002VQ-RQ for larch@yhetil.org; Thu, 10 Sep 2020 04:54:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59848) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGILl-0002V7-II for emacs-orgmode@gnu.org; Thu, 10 Sep 2020 04:54:37 -0400 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]:38600) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kGILj-00004q-Je; Thu, 10 Sep 2020 04:54:37 -0400 Received: by mail-ed1-x52f.google.com with SMTP id c8so5478264edv.5; Thu, 10 Sep 2020 01:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XDU4WyP80cunuBqQt1ciflpQmSCcndR3KeSffn/EW3o=; b=aYN4gSnLfHH8XJJNFXlgacXsDeU8U6UVzrLWJrJPT9EHb5s5hy1O9XUGNMyt4bKz12 dcRSQnVXEMpcvQiaDV9l5JPAR8vVOnKd8i+kKpabhyzKKxx6sW+eI8RapcqqfBDAvkMQ 2E1xmTzZu9CeoIEhpHd290+Ig4alIqSFcJHya9cpj7Rx1yGYnt/tiltorLQ5No2DlHJd Apfh5LBEBqL9ukJJjyQ+Xb0iXsHd7VCkZ8dY8AvmMGSagk2XHrjvFEFTGHxP963DWS+9 Zhnb068SFTTPCzpbf1UL/3nZbJGdmr0zdTLxl//2MS1xCikKV/GyZOdg7YMXZ++kAAFX uvuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XDU4WyP80cunuBqQt1ciflpQmSCcndR3KeSffn/EW3o=; b=pjk12vT/QHDFqvZZQ6DgMdYHTApPV5fWjvGi/CuVaTvBG1KLmTfCgzNtFUThv5Zkqr ZK+Eyw3wAI0U4YpRb8SHgNqOFzywxLNtaurwbvIvZjyJ9jJqgNamy0JKiZWUtUymElSu EdvNwVjf7iO2u3a8lVn+usTwPH+w6NtlI7YaqhE5XOaEsZDZlM1c/SbVXeno9zlefSze RXz+t1WCLSOQE8VjLZTUz406oY17AH0hp6fM5v3zZoVosS5AzMzaX3PZeXS5AOG4pbNW PYMk2SE7/+6mvJ6RKPGrm3/TFvuiGL0NvTf2LO62Uz5290G3Na52J6OakvQsQiYdMoJe dqQg== X-Gm-Message-State: AOAM5322OIvEqcKx/AeQbptHP3DVA0gt26cn/T3qoDnJPC7+hb2bnue9 01p4LwlNjjPbW4YT8NEqrYMMnGjarQ4ebFj/EaGp1EUv7Twp/w== X-Google-Smtp-Source: ABdhPJx9ISd+j+61v+ecjMxsulpEN97DGzJSFPaoJSwXB3Z5njQiF+0TgZIJTNZU2S3UPKBx/ojAGhKJNpiEcKi8Qf8= X-Received: by 2002:a05:6402:503:: with SMTP id m3mr8290168edv.45.1599728073443; Thu, 10 Sep 2020 01:54:33 -0700 (PDT) MIME-Version: 1.0 References: <877dt6ryud.fsf@gnu.org> In-Reply-To: <877dt6ryud.fsf@gnu.org> From: Vladimir Nikishkin Date: Thu, 10 Sep 2020 16:54:21 +0800 Message-ID: Subject: Re: org-babel opens the error output of a block in a separate window... unless :stdin is given, but how are they connected? To: Bastien Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::52f; envelope-from=lockywolf@gmail.com; helo=mail-ed1-x52f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=aYN4gSnL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.71 X-TUID: XrU4lY+7JeL1 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 wrote: > > Hi Vladimir, > > Vladimir Nikishkin 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 <> 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