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: Wed, 19 Feb 2020 23:47:28 +1100 Message-ID: <87h7zmiw0v.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:57342) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4OlO-0001qf-EY for emacs-orgmode@gnu.org; Wed, 19 Feb 2020 07:47:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4OlM-0003VY-5m for emacs-orgmode@gnu.org; Wed, 19 Feb 2020 07:47:38 -0500 Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]:39687) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4OlL-0003Uf-KJ for emacs-orgmode@gnu.org; Wed, 19 Feb 2020 07:47:36 -0500 Received: by mail-pg1-x52e.google.com with SMTP id j15so70241pgm.6 for ; Wed, 19 Feb 2020 04:47:35 -0800 (PST) Received: from tim-desktop (203-173-18-129.dyn.iinet.net.au. [203.173.18.129]) by smtp.gmail.com with ESMTPSA id e84sm2849600pfh.149.2020.02.19.04.47.31 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Feb 2020 04:47:32 -0800 (PST) In-reply-to: <875zg2kcy0.fsf@ucl.ac.uk> 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 I think I agree with Eric here. However, perhaps I don't fully understand all the details. Many shell commans, especially those which mainly perform 'side effects' like echo, return the exit code. This value is often used in shell scripts as a type of short hand/short circuit i.e. combined with logic operators. Question: would it not be import to separate return value from output value when it comes to shell scripts and noweb type expansion e.g. if I had a block where the last command does not do any output, but does return an exit value as the return value, might it not be important to have that exit value for the next babel block which uses the previous block? Something else which may be relevant is to note that bash is not the only shell and some commands, like echo, will behave differently depending on the shell. For exmaple, in some shells, echo with no arguments will just ouput a newline while on other shells, you need to explicitly request this behaviour with -n switch. As a general principal, I think the return value and the output value should be considered to be distinct items and it would be a mistake to return the output value when it appears the last command does not return a value. Do what the shell would do - if it returns the exit code then return that. If the last command really doesn't return anything i.e. hot even an exit code, return nil (though I think under posix, at the very least, the exit code is returned). Fraga, Eric writes: > On Wednesday, 19 Feb 2020 at 12:38, Bastien wrote: >> "0" is the _exit code_ of the successful echo command, not the value >> returned by the echo command. > > But echo does not "return" the string as a value. It outputs the > string. > > To quote the man page for bash, "the return value of a simple command is > its status". Further, a function does not actually return any value > beyond the status of the last command or a value given on a =return= > statement. > >> So In Vladimir's example, both ":results value" and ":results output" >> should return the same result, i.e. ".". > > I disagree. I think the current behaviour (i.e. before your attempt to > "correct"" this) is correct given the documentation you quoted! > >> Was it common to expect the exit code when executing shell code? > > Common? I have no idea. *I* did expect this. But that's maybe because > I do use the shell a lot. > > I think there's a clear distinction between value and output for src > blocks and blurring this distinction for shell src blocks would be > misleading. The option to request the output as the outcome of the src > block is already there. -- Tim Cross