From mboxrd@z Thu Jan 1 00:00:00 1970 From: Derek Feichtinger Subject: Re: Bug or not a bug? dot expansion in ob-shell Date: Fri, 21 Feb 2020 07:55:30 +0100 Message-ID: <87mu9c5t0d.fsf@psi.ch> 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> <87sgj5dld4.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:41749) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j52SS-0001k5-E9 for emacs-orgmode@gnu.org; Fri, 21 Feb 2020 02:10:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j52SO-0005tU-Q1 for emacs-orgmode@gnu.org; Fri, 21 Feb 2020 02:10:41 -0500 Received: from mailg110.ethz.ch ([2001:67c:10ec:5605::21]:3546) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j52SO-0005aj-J3 for emacs-orgmode@gnu.org; Fri, 21 Feb 2020 02:10:40 -0500 In-Reply-To: <87sgj5dld4.fsf@gmail.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 - I also think that this is the correct behavior, and that the average user's expectations can be best fulfilled by making ":results output" the default. Adding the option will make it more difficult to share code blocks and documents. Best regards, Derek On Thu, Feb 20 2020, Tim Cross wrote: > +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. -- Paul Scherrer Institut Dr. Derek Feichtinger Phone: +41 56 310 47 33 Group Head HPC and Emerging Technologies Email: derek.feichtinger@psi.ch Building/Room No. WHGA/U126 Forschungsstrasse 111 CH-5232 Villigen PSI