From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jack Kamm Subject: Re: Bug or not a bug? dot expansion in ob-shell Date: Fri, 21 Feb 2020 22:23:49 -0800 Message-ID: <87tv3jjg22.fsf@gmail.com> References: <87eeur3p1p.fsf@ucl.ac.uk> <87a75eap8k.fsf@gnu.org> <87y2sy3kkl.fsf@ucl.ac.uk> <87r1yq4xiz.fsf@gnu.org> <875zg2kcy0.fsf@ucl.ac.uk> <87h7zmiw0v.fsf@gmail.com> <871rqqag19.fsf@bzg.fr> <87wo8iitzz.fsf@ucl.ac.uk> <87ftf63d79.fsf@gnu.org> <87pnear7tl.fsf@ucl.ac.uk> <87v9o236v1.fsf@gnu.org> <8736b66z6t.fsf@gnu.org> <877e0h571l.fsf@alphaville.usersys.redhat.com> <878skwbc3g.fsf@bzg.fr> <8736b36492.fsf@alphaville.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:44378) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5ODp-0005DA-2p for emacs-orgmode@gnu.org; Sat, 22 Feb 2020 01:25:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j5ODn-0004Nk-Tp for emacs-orgmode@gnu.org; Sat, 22 Feb 2020 01:25:04 -0500 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]:40070) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j5ODn-0004NC-Fx for emacs-orgmode@gnu.org; Sat, 22 Feb 2020 01:25:03 -0500 Received: by mail-pj1-x102f.google.com with SMTP id 12so1735760pjb.5 for ; Fri, 21 Feb 2020 22:25:03 -0800 (PST) In-Reply-To: <8736b36492.fsf@alphaville.usersys.redhat.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: Nick Dokos , emacs-orgmode@gnu.org 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* >> shell blocks: no :results header means "return output" and you need >> to use :results value to get the exit status (your proposal). >> >> 3. Deviate from this strict reading and introduce an option that says: >> "Don't deviate from the Org's and bash manuals for all src blocks". >> >> Obviously, nobody wants the first solution. > > I'm not convinced of that: personally, I would be happy with the first > solution and maybe others would be too. > > My longer term suggestion (which, I realize, does not help to close > *this* case any time soon): > > I think that the global default setting `:results value' is wrong Strongly agree with Nick on both points here. I prefer option 1 over options 2 and 3, I think it is the more consistent and simple behavior. I also think ":results value" is a problematic default. Anecdotally, I use Org-Babel as a computational notebook similar to Jupyter or Rmarkdown, and set ":session :results output" for nearly all my org-babel blocks. Of course, there are many ways in which org-babel can be used, and for some uses, ":results value" is the better default. But for other use cases, including shell blocks, ":results output" is the more intuitive default. And I think this is really the problem here. The result of a shell block is surprising to the new user, because the user probably wants ":results output", but ":results value" is the default. I'm not sure of the solution to this problem, but I don't think it's to change the meaning of ":results value".