From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id QHuhLzDwXmM6QgAAbAwnHQ (envelope-from ) for ; Sun, 30 Oct 2022 22:44:16 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id AMvNLzDwXmMWJQAAauVa8A (envelope-from ) for ; Sun, 30 Oct 2022 22:44:16 +0100 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 511F112491 for ; Sun, 30 Oct 2022 22:44:16 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opG5P-0002tK-U6; Sun, 30 Oct 2022 17:43:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1opG5N-0002tC-P5 for emacs-orgmode@gnu.org; Sun, 30 Oct 2022 17:43:17 -0400 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1opG5I-0002Rn-Jz for emacs-orgmode@gnu.org; Sun, 30 Oct 2022 17:43:14 -0400 Received: by mail-pj1-x1030.google.com with SMTP id q1-20020a17090a750100b002139ec1e999so4407919pjk.1 for ; Sun, 30 Oct 2022 14:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:to:from:user-agent:references:from:to:cc:subject:date :message-id:reply-to; bh=CdgkBJTbmNVuUTwUs2+YfRHaAuSJwWYxNg83Ut4s8Kk=; b=SAU1fTwwTYoL+O+Pev7fVEeEXdphTMe5fP931wxyyLcBoZesGkNFPFN82xNvbuZny/ b0WiLi5jbkNqby/G7IAENX+kJHGgNVNS+Tu6fC+Hkivojn7eCjN5OLCoWBdgRnLSYVVB GgKFf4dAF0TLu1SPmHjCK//GlNBfNTseHppnFTYYKhfAKrPhivgYSfvwNQJ53Y5Y3A8A 1Mc9tpkFdX8TP1SPnuDmGyuflmSSWj06bFdwmr/lXkmNUXlc0MYQ+Uyjk0+R3SMQd/lp Cx/PEKFF7Ak3XlSVTtL3Tyqe0tSEjAcIHkLmWXl+Nmzz0HFESnk/K/iA290WYd9nLedG RZTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:to:from:user-agent:references:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CdgkBJTbmNVuUTwUs2+YfRHaAuSJwWYxNg83Ut4s8Kk=; b=ZYtM10s2x02LrICmFxAVe+PbqO+Bo0Bwc9x9KFbgFaOONsNSoTxJz8tSoxYTS0T6r/ /k/49AlYb1L6wYY/1rhL3h0jKEm7k+AqubepFClol08qN32kC4c/+d/1EWzgbvyCIchl MYSiZDUYGdGLGbZJVmqOPi/COv2s9L5do2y40vy3HqS8CB9/LvX3DXgQAO0dIbuh4IsA L4HRiYxUGtjFp06DJeM1n7/0+RArcdOGWmTgy4ipyf2wXFE7dt091DKt/V902DjDcpa/ +eiimftBfLvsO+cQMKy6wvDHIjWQkvvhqs7qRb3lmymtKSI2d1r2clB3DAV2BZrsTogm 09wg== X-Gm-Message-State: ACrzQf2ZkAVYGnZK2s8kmZPc7wBY3m9adMZqcJnuAATZ7nfiQEylMtwL nwoL7CqgBfQLbkePJqx8VavpqN2wWUQ= X-Google-Smtp-Source: AMsMyM7UyoyauGiQgYQaou2f2xelc+buRPwixAwM0VG9hJBf0BVewqcXmu5igUWfYNj3N+HWxYY15w== X-Received: by 2002:a17:90b:4d90:b0:213:687d:c0f0 with SMTP id oj16-20020a17090b4d9000b00213687dc0f0mr11655208pjb.212.1667166190624; Sun, 30 Oct 2022 14:43:10 -0700 (PDT) Received: from dingbat (220-235-181-183.dyn.iinet.net.au. [220.235.181.183]) by smtp.gmail.com with ESMTPSA id e18-20020a17090301d200b00186b945c0d1sm3099445plh.2.2022.10.30.14.43.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Oct 2022 14:43:09 -0700 (PDT) References: <87edvbysqc.fsf@localhost> <87r0z6j1b1.fsf@localhost> <87pmel68y6.fsf@localhost> <87o7u432tl.fsf@localhost> <87a65o15ut.fsf@localhost> <87fsffqi49.fsf@localhost> <87wn8lorc1.fsf@localhost> <87v8o4krel.fsf@localhost> <87tu3njmv4.fsf@localhost> User-agent: mu4e 1.9.1; emacs 29.0.50 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: [FR] Display stderr contents after executing shell blocks (even when stdout :results output is requested) (was: Org 9.6-pre and Bash sessions) Date: Mon, 31 Oct 2022 07:28:37 +1100 In-reply-to: <87tu3njmv4.fsf@localhost> Message-ID: <865yg1c7is.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1030.google.com 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.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Emacs-orgmode" Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1667166256; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=CdgkBJTbmNVuUTwUs2+YfRHaAuSJwWYxNg83Ut4s8Kk=; b=GhU63qQQuqO+28IWG8VIX8/YpqBzGeyCKDmccKsMQ8FGYvZd3wbzrfKP1fQ5ICopCFp/xK asngZyiTcnRouhnpArLhHMcW1LvPlNcdTrly/TG/hRY/QvzgSsKW5mMVgjdNXIdwodegIp fxEVnN6htAp1MqoaHDKm8tO7hZEJ+6MdSdL6Jj+HlXVkrMIlg4vjNlXmQ2C6wGA2dRzFQP CLVCxkGxOLP0zDCgsLbMnfyknYhBMk8ngDDDClTG5s4ZOxC1PZJg2v4spGB9udf/lcEpPf nLqLaOE5OUGJz/PbxsKSdiulkKUEwPDf6v2eC0iAAspekIXaz3Sd9gTMi+ncUg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1667166256; a=rsa-sha256; cv=none; b=QXzMGUNXAomrIyTFJP2ZnogdJE1Kdgo1NzupYxlMaNDInEqhb/UOfrkHyTWNiftw9viCFE fHDSjWb+FLTGOnAtdz2PkE/qFtp2V7KQ+ppNM3cztrYGiHguixENSUgjJ8v6+vy4lTdakp x327MSZyqUOLMFoTmQq7zRtK3mMzwpwemeKKaFcMZhwHa4ZoEH7uyJk72d4AStS9K+J3VG HgFHUHIGfAbQ5jIjL57tfAO14MU7k3eByX6aVCj8XGZKgG1o4WfuFlZa8HPzzrzqsl5OEE C5NdkKdTFWdDFgliAGfB77GJehNLgrEC75daq0MlluMMAmz6ynyW3Qwg2ggluQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SAU1fTww; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.96 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SAU1fTww; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 511F112491 X-Spam-Score: -3.96 X-Migadu-Scanner: scn1.migadu.com X-TUID: 5Xs30tRy3fGv Ihor Radchenko writes: > Rudolf Adamkovi=C4=8D writes: > >> Ihor Radchenko writes: >> >>> I do not think that it make sense to display that buffer when the code >>> finishes successfully. I can see this kind of behaviour >>> breaking/spamming automated scripts or export---code working in the >>> past may throw error output into unsuspecting users. >> >> But the exit code has nothing to do with the standard error. >> >> Unix programs can, and often do, halt with non-zero exit codes while >> producing error output containing important information, such as >> deprecation warnings. Further, many programs use error output as the >> alternative "anything but the result" stream. >> >> Preserving user data, instead of trashing it, data does not count as >> "spamming ... unsuspected users". On the contrary! >> >> For example, I use a program for work that uploads data to a certain >> 3rd-party server. It exits with a zero code but also shows extremely >> important notices on error output. As an "unsuspecting user", if I used >> Babel to run the program, I would end up in a trouble. >> >> So, we should never implicitly trash user-generated data, let alone >> based on a "completely made up" belief that a non-zero exit code somehow >> implies "no important error output". It does not. >> >> (I speak only about Unix-like systems here. Perhaps on other operating >> systems, things work differently.) > > Dear All, > > As explained in the above quote, it may be reasonable to display stderr > in the shell (and possibly other) src blocks upon execution. > > + Stderr may contain important information even if the code block > succeeds > - Displaying stderr will raise *Error* buffer, which may or may not be > expected or desired. > > What do you think? I think this is perhaps the tip of a more complex iceberg. Not sure if we can address bits individually. Suspect we are better off clarifying the basic babel model and then look at specific language exceptions/limits and adjusting the model or documenting where back ends need to diverge from the basic model. Part of the challenge here is that the relevance/importance of stderr is somewhat dependent on the language. Same holds true for handling of error/return codes and to 'results' output. For me, this is another symptom of our need to define a clearer model for babel processes so that we can get some consistency across the board. Such a model would likely also make it easier for people to develop new babel back ends. We may even need 2 models, one for interactive/repl based back ends and one for non-interactive/scripted back ends.=20 The 2 big questions I see are "What should be defaults be?" and "How do we handle the options without adding lots of new switches or suffering an option permutation blow out?". I do agree with the other posts regarding the importance of stderr.