From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Bug or not a bug? dot expansion in ob-shell Date: Wed, 04 Mar 2020 13:41:41 -0500 Message-ID: <87o8tc0xp6.fsf@alphaville.usersys.redhat.com> References: <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> <87imjyoi99.fsf@gnu.org> <87y2slqudr.fsf@gmail.com> <87y2sltnas.fsf@gmail.com> <87sgiszqc1.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:33336) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9Yxs-0002dM-7L for emacs-orgmode@gnu.org; Wed, 04 Mar 2020 13:41:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j9Yxr-0004S3-4Y for emacs-orgmode@gnu.org; Wed, 04 Mar 2020 13:41:52 -0500 Received: from ciao.gmane.io ([159.69.161.202]:37160) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j9Yxq-0004Q7-UW for emacs-orgmode@gnu.org; Wed, 04 Mar 2020 13:41:51 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1j9Yxm-0001vq-N9 for emacs-orgmode@gnu.org; Wed, 04 Mar 2020 19:41:46 +0100 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 Hi Tim, Tim Cross writes: > It seems to me that two separate issues have been mixed up and causing > some confusion here. However, I think it is actually quite simple once > we consider the issues separately. > > Issue 1: Defining the meaning of :result value and :result output > Issue 2: Specifying what the default :result setting would be i.e. > :result without a value/output specifier. > > Issue 1 seems the most straight-forward to me > - output :: Whatever goes to stdout/stderr > - value :: whatever would be returned by the execution of the code. This > might be a return value (i.e. for some shell commands) or the value > returned by a function (including shell functions i.e. bash function) or > the last command executed etc. Essentially, anything returned (including > nil) by the block. STDOUT/STDERR is never a return value (though some > languages may send output to STDOUT/STDERR as well as returning it, in > which case it would also be in :return value). > > Note that I don't agree that the only 'useful' result from shell blocks > is output. You might have a complex shell script which uses source > blocks to define shell functions > that return values which you use via oweb expansion to include in other > blocks etc.s > > With this definition, essentially :result value is essentially anything > except whatever is sent to stdout/stderr. > > Issue 2 is a little more difficult. It is likely that a 'standard' > default for :result that is the same for all languages is not > possible/desired. The default will likely be a combination of what seems > most natural for that language and what is most common usage for the > majority of users. It could be that for some languages, the default for > :result should be :result output and for others it should be :result > value. > > Personally, I care less about issue 2 than issue 1. In the worst case, I > will need to change my header arguments for some blocks and that would > be easily automated. Far more critical is that :result value and :result > output are clear, unambiguous and consistent. Any proposal to change > these meanings because of different uses cases in languages is a bad > idea. Instead, changing the 'default' would be preferable. Having shell > source blocks return STDOUT/STDERR output for :result value is IMO a bad > idea. Having shell blocks default to :result output when only specifying > :result while having other languages, like python or clojure default to > :result value seems far more preferable (provided differences are > clearly documented of course). > ... Thanks for the (very clear) write-up. I can only nod my head in violent agreement :-) -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler