From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Gillespie Subject: Re: Bug or not a bug? dot expansion in ob-shell Date: Sat, 29 Feb 2020 18:08:23 -0800 Message-ID: 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> <87imjyoi99.fsf@gnu.org> <87y2slqudr.fsf@gmail.com> <87y2sltnas.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:50184) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j8E24-0006Gf-KX for emacs-orgmode@gnu.org; Sat, 29 Feb 2020 21:08:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j8E23-0008Tx-DS for emacs-orgmode@gnu.org; Sat, 29 Feb 2020 21:08:40 -0500 In-Reply-To: <87y2sltnas.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: Jack Kamm Cc: Bastien , Nick Dokos , emacs-orgmode@gnu.org Hi all, Sorry to be late to this thread (and for a wall of text), but as a heavy user of ob-shell I wanted to chime in. First a disclosure, I would be very unhappy if option 1 were selected, it would require me to make a whole bunch of changes and try to find an option to revert to the current default behavior. When I run a bash block in org mode, I want what is going to stdout, why else would I run it in org? If I don't want to capture the output then it is either in a pipeline inside the block, or I will silence the results. Option two is by far the most reasonable answer in my opinion and there is a consistent principle which can be applied in many cases so that it would not be an exception. The principle is that block defaults for results should default to the value that the language itself makes the most accessible. Shell return codes are esoteric from this point of view, I had been writing bash scripts for years before I learned about $?. By far the most actionable and accessible thing to a user of a shell program is the stdout -- ignore the naming for a moment, because the meaning is not in the name, it is in how it interacts with other programs in the larger environment. If we apply the logic that says that option 1 should be the default, then python blocks set to results value should return nothing unless an error is raised and then they should return the error. This is clearly absurd, no python programmer cares about the absence of an error and making the default behavior of python blocks verbosely report their non-errorness by default would likely incite a riot. What has happened with shells is that the nomenclature has been switched with respect to how users and other code consume and deal with 'outputs' aka return values in any other langues, shell return values are error signals and should be treated as such, unfortunately (or perhaps fortunately?) org-mode doesn't have an error handling/signaling system, but if a python code block fails emacs will yell at us, shells don't do this, it is up to the user to detect and handle the error case themselves, but that is a language internal matter. In summary, option 2 seems to me to be the most consistent with how users interact with shell commands and shell scripts, return codes are more akin to error handling in other languages, so ignoring the naming issues, if `my-org-block` behave like a shell function, then pipe would be the more appropriate default behavior than `$?`. I think that the underlying principle can be applied to other languages as well to arrive at sane defaults. Thoughts? Tom On Sat, Feb 29, 2020 at 7:41 AM Jack Kamm wrote: > > Sorry, I was confused about this: > > > According to my reading of this thread, most of the commenters were in > > agreement that we should keep the original behavior and return the exit > > code, as we do in 9.3. > > Actually, it looks like ":results value" does return the exit code. I > just got confused because shell blocks now return the output when no > ":results" is specified. >