From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Cross Subject: Re: Bug or not a bug? dot expansion in ob-shell Date: Fri, 21 Feb 2020 08:01:11 +1100 Message-ID: <87sgj5dld4.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:45318) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4swi-00083w-2z for emacs-orgmode@gnu.org; Thu, 20 Feb 2020 16:01:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4swg-0002on-JK for emacs-orgmode@gnu.org; Thu, 20 Feb 2020 16:01:19 -0500 Received: from mail-pg1-x530.google.com ([2607:f8b0:4864:20::530]:39220) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4swg-0002mx-C9 for emacs-orgmode@gnu.org; Thu, 20 Feb 2020 16:01:18 -0500 Received: by mail-pg1-x530.google.com with SMTP id j15so2528742pgm.6 for ; Thu, 20 Feb 2020 13:01:18 -0800 (PST) Received: from tim-desktop (203-173-23-57.dyn.iinet.net.au. [203.173.23.57]) by smtp.gmail.com with ESMTPSA id d14sm480131pfq.117.2020.02.20.13.01.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2020 13:01:15 -0800 (PST) In-reply-to: <877e0h571l.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: emacs-orgmode@gnu.org +1 - this is basically my feeling as well. I've spent the last couple of days thinking about the additional option suggestion, but something just didn't feel right to me. I think Nick has hit the nail on the head. Adding the additional option seems to be making things more confusing. The basic idea that result value is what the block returns i.e. the return value of the last statement for shell blocks and result output is what the code in the block sends to stdout/stderr. This seems the most intuitive to me. Nick Dokos writes: > Hi Bastien, > > Bastien writes: > >> Hi Diego, >> >> Diego Zamboni writes: >> >>> I'm late to the discussion so I apologize in advance, but this fix >>> seems counterintuitive to me. In my mind, for any shell code: >>> >>> - Return value: exit code of the last command >>> - Output: whatever the commands print >> >> Yes, that's what is *now* possible if you set >> ob-shell-return-value-is-exit-status to t. >> >> Unless I miss something, it was not possible before today. >> >> #+begin_src shell >> echo Hello! >> #+end_src >> >> would simply return "Hello!" as a return. >> >> No exit code was *never* output. >> >>> So to me, it's intuitive that =:exports value= would return the exit >>> code of the last command, and =:exports output= would produce the >>> output of the commands. I don't understand why a new option is >>> needed. >> >> ... because it was not the case before. Or maybe *I* miss something. >> >> Can you show me something that was working before and that is not >> anymore? >> >> Thanks, > > I welcome the fix but not the option: the option situation in Org mode > was pretty horrible, then ca 2010, you did a survey and some options > were eliminated (not sure about the year or whether it *was* you who > did the survey, but I'm pretty sure there was one): that was the right > direction to go, but it wasn't enough. Org mode needs to be put into > an option diet, so adding another one here (and a rather gratuitous > one in my view) is not the way to go. > > `:results value' should *always* produce the value of the last expression, > which for shell programs is the exit status of the last command. > > `:results output' should *always* produce all of the output of the program. > > An argument can be made that `:results value' is the default, but it > is the less useful option for shell programs. So maybe for shell > blocks, make the default to be `:results output' instead: people get > what they always got before the fix without lifting a finger, the exit status > is now available with `:results value', and the option can go away > quietly and quickly, before it becomes another contributor to the Org > mode technical debt. -- Tim Cross