From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id qH1mCmpwVl/oAQAA0tVLHw (envelope-from ) for ; Mon, 07 Sep 2020 17:39:54 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id kHJCBmpwVl+IZQAAB5/wlQ (envelope-from ) for ; Mon, 07 Sep 2020 17:39:54 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AEE28940142 for ; Mon, 7 Sep 2020 17:39:53 +0000 (UTC) Received: from localhost ([::1]:43374 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFL7Q-0003wk-8w for larch@yhetil.org; Mon, 07 Sep 2020 13:39:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32982) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFL6y-0003wA-43 for emacs-orgmode@gnu.org; Mon, 07 Sep 2020 13:39:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46581) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFL6x-0007Ye-Qq; Mon, 07 Sep 2020 13:39:23 -0400 Received: from lns-bzn-32-82-254-31-120.adsl.proxad.net ([82.254.31.120]:51342 helo=guerry) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1kFL6x-0006TX-3X; Mon, 07 Sep 2020 13:39:23 -0400 Received: by guerry (Postfix, from userid 1000) id F04811A60D90; Mon, 7 Sep 2020 19:39:20 +0200 (CEST) From: Bastien To: Jack Kamm Subject: Re: Bug or not a bug? dot expansion in ob-shell Organization: GNU References: <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> <87d09wd8c5.fsf@gmail.com> <87wo84ehvx.fsf@gmail.com> <87tv38dqn5.fsf@gmail.com> <87mu22zu1e.fsf@gnu.org> Date: Mon, 07 Sep 2020 19:39:20 +0200 Message-ID: <877dt5trjr.fsf@bzg.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tom Gillespie , emacs-orgmode@gnu.org, Nick Dokos Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: 2mG9+sg2BuqR Bastien writes: > At first, I thought "If ':results value' is always the same as the > default, why have ':results value' at all?" and thought it'd be an > argument for having different defaults for different languages but > I see how I was wrong: expectations for defaults should be stable, > while the notion of "value" and "output" can vary from one language > to the other. Sooooo! I've thought about this again and here we are. The default is to not break the previous behavior, which is to use the output of shell scripts, not their exit codes. This is because (1) I don't like incompatible changes (2) the output is what most users want anyway and (3) a default of :results value would break the default behavior for src_sh{echo "this"} (and asking users to update to src_sh[:results output]{echo "this"} is a bad option.) If you want to stick to the :results value as the default, you can set org-babel-shell-results-defaults-to-output to nil. Yes, a new option, but at least now we have a clear convention: the default for all Babel libraries should be to stick to ":results value" when no :results header is set (as the manual suggests) ; when deriving from this, a library should add an option to do so. I strongly believe that having an option is better than implicitely changing the default expectation when no :results header is set, it is more predictable for users. I hope this all makes sense. -- Bastien