From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
Received: from mp1.migadu.com ([2001:41d0:303:e16b::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms1.migadu.com with LMTPS
	id EIdHMASTJ2bUGAAA62LTzQ:P1
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Tue, 23 Apr 2024 12:52:52 +0200
Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp1.migadu.com with LMTPS
	id EIdHMASTJ2bUGAAA62LTzQ
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Tue, 23 Apr 2024 12:52:52 +0200
X-Envelope-To: larch@yhetil.org
Authentication-Results: aspmx1.migadu.com;
	dkim=none;
	spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org";
	dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org;
	s=key1; t=1713869572;
	h=from:from:sender:sender:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:list-id:list-help:
	 list-unsubscribe:list-subscribe:list-post;
	bh=+jBWXtmcxQOvBlAkAa/kCBLfZSymDws0nEGzOsp/u7k=;
	b=fFc1IBhA8NKFy/qC5m5wgfdt1ysaG8QNw6I1QJk2B+6uFm2yrkcFR8SGk2DH5GzF42Z+Av
	pPnXOCRv1e0G5cErNBNSvMEL6+xsCieoWrdy+tANIJ6kwqBu1jW0bUraaEdwdfPW64IJpV
	yl9CRl5Vrf9Kn7vA586O8DZ0zBBB0alvD5pC/rWYtnlkfP2FuOkxp4cDVfhIwcMWpXijAj
	SYpZDHqKL5YA+T05aWNsZl2cHvk9OpCXhrYb8ejkuoVFqK4Jw6gTKj0phO8HJ2E+nbEeN1
	esOU42bgdRkeDE5TkgpAN6zMQ1r8CqeTsWSO3X6wV6z0/0aPJnC/IVA21bIkJw==
ARC-Seal: i=1; s=key1; d=yhetil.org; t=1713869572; a=rsa-sha256; cv=none;
	b=mbsoDBIjxf65RMA62+qGwf6u/zlTU6jMHVEWMjPArA0gOp98YoYHI3bAMVeZBjjeuU73cE
	NjU6AoydpQfxmk/owQH4tl+OdTeIbhLP4x+32viQQlFjdGtum9GOw4rdaXGtB5oCyEp5rB
	Ktmn2iKjGjek7cct0xOWDu6HNjDKqu5FBcY7s7E5A1CbgPjKdSQxlSwtQXXSRkXT2oM6NL
	ron3M0kZcuWhhAutRLWFU6zLt0fnpPcMqhO+3ZuUSJEy41wP/NTWrHscGLBiIQi5s76Zv5
	MESdTErMMiTis/JR+jJdnN8sn45+oPZAVBoMDL7LWO0nBUlSNJgD/Ls2C4EYyQ==
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=none;
	spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org";
	dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none)
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 7062761175
	for <larch@yhetil.org>; Tue, 23 Apr 2024 12:52:52 +0200 (CEST)
Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-orgmode-bounces@gnu.org>)
	id 1rzDkX-000392-2a; Tue, 23 Apr 2024 06:51:45 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <geo-emacs-orgmode@m.gmane-mx.org>)
 id 1rzDkW-00038A-8y
 for emacs-orgmode@gnu.org; Tue, 23 Apr 2024 06:51:44 -0400
Received: from ciao.gmane.io ([116.202.254.214])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <geo-emacs-orgmode@m.gmane-mx.org>)
 id 1rzDkT-0006bX-Tv
 for emacs-orgmode@gnu.org; Tue, 23 Apr 2024 06:51:43 -0400
Received: from list by ciao.gmane.io with local (Exim 4.92)
 (envelope-from <geo-emacs-orgmode@m.gmane-mx.org>)
 id 1rzDkP-0005uq-5C
 for emacs-orgmode@gnu.org; Tue, 23 Apr 2024 12:51:37 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: emacs-orgmode@gnu.org
From: Max Nikulin <manikulin@gmail.com>
Subject: Re: [PATCH] Re: [BUG] ob-shell: :shebang changes interpretation of
 :cmdline
Date: Tue, 23 Apr 2024 17:51:30 +0700
Message-ID: <v083rk$llm$1@ciao.gmane.io>
References: <ujamo1$5t9$1@ciao.gmane.io>
 <18f01342a2f.124ad27612732529.8693431365849276517@excalamus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird
Content-Language: en-US, ru-RU
In-Reply-To: <18f01342a2f.124ad27612732529.8693431365849276517@excalamus.com>
Received-SPF: pass client-ip=116.202.254.214;
 envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io
X-Spam_score_int: 26
X-Spam_score: 2.6
X-Spam_bar: ++
X-Spam_report: (2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001,
 FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309,
 FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.248, NML_ADSP_CUSTOM_MED=0.9,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-BeenThere: emacs-orgmode@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
X-Migadu-Country: US
X-Migadu-Flow: FLOW_IN
X-Migadu-Spam-Score: -5.77
X-Spam-Score: -5.77
X-Migadu-Queue-Id: 7062761175
X-Migadu-Scanner: mx13.migadu.com
X-TUID: vyQdkD/zw2x2

On 21/04/2024 22:09, Matt wrote:
> The proposed solution assumes we intend to parse the characters
> following :cmdline as space delimited and grouped by quotes.  However,
> AFAICT, the parsing issue makes this solution ambiguous.

Matt, I am sorry, but I do not agree with your proposal. I do not think 
that `split-string-and-unquote' will solve all issues.

Certainly issues with formatting of output should be treated separately.

I figured out there is at least one more issue. Consider

#+property: header-args:bash :results verbatim
#+begin_src bash :cmdline $LANG :shebang #!/bin/bash
   printf '"%s" ' "$0" "$@"
   printf '\n'
   tr '\000' '\n' </proc/$$/cmdline
#+end_src

#+RESULTS:
: "/tmp/babel-Is56Ki/sh-script-8FluOx" "$LANG"
: /bin/bash
: /tmp/babel-Is56Ki/sh-script-8FluOx
: $LANG

#+begin_src bash :cmdline $LANG
   printf '"%s" ' "$0" "$@"
   printf '\n'
   tr '\000' '\n' </proc/$$/cmdline
#+end_src

#+RESULTS:
: "/tmp/babel-Is56Ki/sh-script-g0cQ7R" "en_GB.UTF-8"
: /usr/bin/bash
: -c
: /tmp/babel-Is56Ki/sh-script-g0cQ7R $LANG

First line is argv as it is represented for a script, next lines are 
exec arguments at lower level (actual executable may be obtained from
"readlink /proc/$$/exe")

Notice that in the former case "$LANG" is passed literally, but in the 
latter it is expanded. I am in favor of dropping `shell-command-switch' 
in the latter case to pass arguments literally in both cases.

I think, it would be more consistent with :var to specify multiple 
arguments using elisp lists
#+header: :cmdline '("first 1" "second 2")

However looking wider, I do not like that :cmdline for ob-shell has 
different meaning than for other languages, see e.g. ob-sql. Only for 
shell this parameter is treated as arguments of a *script*. In other 
cases :cmdline is used to specify arguments of *interpreter* and I think 
ob-shell should follow this convention.

Actually script arguments (and :stdin) might be applied to python and at 
least some other languages, so support of this feature should be moved 
from ob-shell to common org-babel code.

My point:
- header arguments should have as close as possible meaning across 
various languages.
- withing ob-shell variation of ways to execute a script should be 
minimized either some parameters (:cmdline, :shebang, :stdin) are 
specified or not.

Finally a note on tests
> +(ert-deftest test-cmdline-alone-and-with-shebang-have-same-result ()
> +  "Pass arguments to a block.  Don't use shebang.  Then use
> +shebang set to the same language as the block.  The result should
> +be the same."
> +  (should (equal
> +           (org-test-with-temp-text
> +               "#+begin_src bash :cmdline 1 2 3
> +echo \"$1\"
> +<point>
> +#+end_src"
> +             (org-babel-execute-src-block))
> +           (org-test-with-temp-text
> +               "#+begin_src bash :cmdline 1 2 3 :shebang #!/usr/bin/env bash
> +echo \"$1\"
> +<point>
> +#+end_src"
> +             (org-babel-execute-src-block)))))
I believe, that starting point of the discussion is that the results 
should be same and decision what is more correct is the result of the 
discussion. Unit tests should check both cases independently and should 
fix particular treatment of arguments.