From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id YF94HVIsJWZ0SwEA62LTzQ:P1 (envelope-from ) for ; Sun, 21 Apr 2024 17:10:10 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id YF94HVIsJWZ0SwEA62LTzQ (envelope-from ) for ; Sun, 21 Apr 2024 17:10:10 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=excalamus.com header.s=zmail header.b=I95IkDaX; 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=none; arc=pass ("zohomail.com:s=zohoarc:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1713712210; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=xVJmjQmtKwSvnuCSt+qiheBNy41jIL44+FFQTUtXnfI=; b=K26iJE9dRtYvZ5lRFcJAF/zEygZf81kXs6HTC//M1+DoqEZbZLERHYmkfKlAdSDJtwDNH5 J/Qlosmhr3u4PKC79d4H8ESoZssgnyNTnjb9J+2eEA2fEroZ0v9flT8wSlxIJSW8TUrAH2 +lydmwp7X2h7hbbkR51+EGTp5LsTlxZdD/UUXXrWXl72PjoJ2XPGDj9d0dqavRrNxStibg FpnFoRUWv9XKHtBcikUz/nbmz3wbdQ1ls+atevLvUtKjhX7LaNIVz3rnWCmaaeszo15i+d x/sk6RMnhz5+bRZ4wK03TbhfLQYUPw86t64Tj3vl73qkUFA0iTNVZsatnaQWyA== ARC-Seal: i=2; s=key1; d=yhetil.org; t=1713712210; a=rsa-sha256; cv=pass; b=IooPYSKgKn15muOdOa1hfesb8W2Lhyp6qdCUWoUtjU/PuB2ZwTC+zcpKcQN8FLtSOkT5vI gedpiZYq1bow8B7Ssjjm/1iK0kqY7EsFWEynuJrALth/j6lu37UDNxnpUIOBWNVJfbgseE swBklsSnGhDhYk5icrW4/vkXcQTJDwoHKDv20ocJ73ussM4DpjLLJ6E6SUngGLo/dYLm2o +K7a9/r8iOW7zWkvuFTfODSdOKjKayIiLrAD77A7hj+cd/dqN8QH4nlcazOLsAnqe8LFct gV1wN81k14mdNdWDMCLDfOvov43tVFIGaz3l9n/KxDbcTIjw37Uww3NBkMgkfA== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=excalamus.com header.s=zmail header.b=I95IkDaX; 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=none; arc=pass ("zohomail.com:s=zohoarc:i=1") 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 0CB7364F3B for ; Sun, 21 Apr 2024 17:10:09 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ryYoh-0000Sl-Or; Sun, 21 Apr 2024 11:09:19 -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 ) id 1ryYog-0000Sa-Gr for emacs-orgmode@gnu.org; Sun, 21 Apr 2024 11:09:18 -0400 Received: from sender4-op-o12.zoho.com ([136.143.188.12]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ryYoe-00021Z-6A for emacs-orgmode@gnu.org; Sun, 21 Apr 2024 11:09:18 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1713712149; cv=none; d=zohomail.com; s=zohoarc; b=DUOrqfQmbPPKsLggIKnYUShpCIGkt/ap38m2Sy8GSoVoYajrtvD09J6sih3Y5Ti9XPJDuSC9vYhGs3w2SC96Hy9yB9rfzFhnceWbpCb4d+Ga7ROJeBwiCl8z7P4rCxzF58Pnebg9yw1WlVNRHqwt0yXCV6eTU3/jIrr+cSs/fk8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1713712149; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=xVJmjQmtKwSvnuCSt+qiheBNy41jIL44+FFQTUtXnfI=; b=JsJFYJTsu+4iZq5TtjlqOJFUd64r4WXGpyO+s6EeOIa2s6qwsO3aMDwveC0GV+Nv5465p5zdqXdNIUrsEY2H+zPgVX6XX+fN6tfEv9UjzfAT53Eef7iLiyvMrO599IZ5Uy1KRjzULOsrjL563wK+DWEuhGdHXolHWcrW5RCTzWw= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=excalamus.com; spf=pass smtp.mailfrom=matt@excalamus.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1713712149; s=zmail; d=excalamus.com; i=matt@excalamus.com; h=Date:Date:From:From:To:To:Cc:Cc:Message-Id:Message-Id:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Reply-To; bh=xVJmjQmtKwSvnuCSt+qiheBNy41jIL44+FFQTUtXnfI=; b=I95IkDaXTpLUE5bP74ZyoIpcO3MP7ud/QgHKVCE2Shr40Fnzjizj+t+bmqrJOCDG pajij0wBfCO39+gkak0n5M/WsSXKGbxeJiXRA5hip49xGtdlFGZ4ChhQc90gf9g2nJd OpIlc1jyyz4F4oishY+4T8VnBFD7pFewSjjBWMIM= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1713712147033455.1053831902083; Sun, 21 Apr 2024 08:09:07 -0700 (PDT) Date: Sun, 21 Apr 2024 17:09:06 +0200 From: Matt To: "Max Nikulin" Cc: "emacs-orgmode" Message-Id: <18f01342a2f.124ad27612732529.8693431365849276517@excalamus.com> In-Reply-To: References: Subject: [PATCH] Re: [BUG] ob-shell: :shebang changes interpretation of :cmdline MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8939229_975561990.1713712146992" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Zoho-Virus-Status: 1 X-Zoho-AV-Stamp: zmail-av-1.1.0/213.622.87 Received-SPF: pass client-ip=136.143.188.12; envelope-from=matt@excalamus.com; helo=sender4-op-o12.zoho.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -10.35 X-Spam-Score: -10.35 X-Migadu-Queue-Id: 0CB7364F3B X-Migadu-Scanner: mx12.migadu.com X-TUID: yxTCV1a4uKX3 ------=_Part_8939229_975561990.1713712146992 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---- On Sat, 18 Nov 2023 16:54:39 +0100 Max Nikulin wrote ---=20 > Hi, >=20 > Trying to figure out the origin of the confusion with > "bash -c bash /path/to/file-containing-the-source-code.sh" > I have faced an inconsistency with :cmdline treatment in ob-shell.el. I= =20 > expect same results in the following cases: >=20 > #+begin_src bash :cmdline 1 2 3 > printf "%s\n" "$1" > #+end_src >=20 > #+RESULTS: > : 1 >=20 > #+begin_src bash :cmdline 1 2 3 :shebang #!/bin/bash > printf "%s\n" "$1" > #+end_src >=20 > #+RESULTS: > : 1 2 3 >=20 > Emacs-28, Org is the current git HEAD. AFAIU, the inconsistency is due to how the characters following :cmdline ar= e interpreted when the subprocess call is made. Consider the following, when only :cmdline is used: # Evaluates like: # # bash -c "./sh-script-8GJzdG 1 2 3" # #+begin_src bash :cmdline 1 2 3 echo \"$1\" #+end_src #+RESULTS: : 1 # Evaluates like: # # bash -c "./sh-script-8GJzdG \"1 2\" 3" # #+begin_src bash :cmdline "1 2" 3 echo \"$1\" #+end_src #+RESULTS: : 1 2 For :cmdline alone, the characters following :cmdline are passed as though = each is quoted. That is, separate arguments are delimited by one or more s= paces. The first example is equivalent to the following: # Evaluates like: # # bash -c "./sh-script-8GJzdG \"1\" \"2\" \"3\"" # #+begin_src bash :cmdline 1 2 3 echo \"$1\" #+end_src #+RESULTS: : 1 How would you expect :cmdline "1 2 3" to be evaluated? #+begin_src bash :cmdline "1 2 3" echo \"$1\" #+end_src My expectation would be that it evaluates like: bash -c "./sh-script-8GJzdG \"1 2 3\"" It turns out, however, that it's evaluated exactly like :cmdline 1 2 3, or = :cmdline "1" "2" "3". The result is "1". To make the block evaluate as expected requires an extra set of parentheses= : # Evaluates like: # # bash -c "./sh-script-8GJzdG \"1 2 3\"" # #+begin_src bash :cmdline "\"1 2 3\"" echo \"$1\" #+end_src #+RESULTS: : 1 2 3 This, however, appears to be separate from the reported issue[fn:1]. Now, consider :cmdline paired with :shebang, called with the same values as= above. # Evaluates like: # # /tmp/babel-Xd6rGS/sh-script-61jvMa "1 2 3" # #+begin_src bash :cmdline 1 2 3 :shebang #!/usr/bin/env bash echo \"$1\" #+end_src #+RESULTS: : 1 2 3 # Evaluates like: # # /tmp/babel-Xd6rGS/sh-script-61jvMa "\"1 2\" 3" # #+begin_src bash :cmdline "1 2" 3 :shebang #!/usr/bin/env bash echo \"$1\" #+end_src #+RESULTS: : 1 2" 3" # Evaluates like: # # /tmp/babel-Xd6rGS/sh-script-61jvMa "1 2 3" # #+begin_src bash :cmdline "1 2 3" :shebang #!/usr/bin/env bash echo \"$1\" #+end_src #+RESULTS: : 1 2 3 # Evaluates like: # # /tmp/babel-Xd6rGS/sh-script-61jvMa "\"1 2 3\"" # #+begin_src bash :cmdline "\"1 2 3\"" :shebang #!/usr/bin/env bash echo \"$1\" #+end_src #+RESULTS: : 1 2 3"" # Evaluates like: # # /tmp/babel-Xd6rGS/sh-script-61jvMa "\"1\" \"2\" \"3\"" # #+begin_src bash :cmdline "1" "2" "3" :shebang #!/usr/bin/env bash echo \"$1\" #+end_src #+RESULTS: : 1" "2" "3"" An immediate observation is that the output results don't format correctly.= If you change the results type to "raw", however, you'll see that the Org= results match those from a terminal, like xfce4-terminal. The fact that r= aw output matches output from the terminal means that the formatting issue = is (also) separate from the bug we're trying to fix. That is, the bug we'r= e trying to fix occurs in how the subprocess call is made, not in how the r= esult is formatted. In ob-shell, the subprocess call is made with 'process-file'. Arguments ar= e determined casewise: 1. shebang+cmdline 2. cmdline The characters following :cmdline are received by the 'cmdline' argument to= 'org-babel-sh-evaluate' as a string. Both cases put this string into a li= st for the ARGS of 'process-file': | header | 'org-babel-sh-evaluate' | process-file ARGS | | | cmdline variable value | shebang+cmdline | |----------------------+-------------------------+-----------------------| | :cmdline 1 2 3 | "1 2 3" | ("1 2 3") | | :cmdline "1 2" 3" | "\"1 2\" 3" | ("\"1 2\" 3") | | :cmdline "1" "2" "3" | "\"1\" \"2\" \"3\"" | ("\"1\" \"2\" \"3\"") | | header | 'org-babel-sh-evaluate' | process-file ARGS | | | cmdline variable value | cmdline | |----------------------+-------------------------+-----------------------| | :cmdline 1 2 3 | "1 2 3" | ("1 2 3") | | :cmdline "1 2" 3" | "\"1 2\" 3" | ("\"1 2\" 3") | | :cmdline "1" "2" "3" | "\"1\" \"2\" \"3\"" | ("\"1\" \"2\" \"3\"") | Notice that the ARGS passed to 'process-file' are the same for both cases. = The problem is that the "block equivalent shell calls" are *not* the same.= If we arrange the equivalent shell calls from the blocks given above into= a table, we see that the forms are different: | header | cmdline variable value | shebang+cmdline call = | |----------------------+------------------------+--------------------------= ------------------------------| | :cmdline 1 2 3 | "1 2 3" | /tmp/babel-Xd6rGS/sh-scri= pt-61jvMa "1 2 3" | | :cmdline "1 2" 3" | "\"1 2\" 3" | /tmp/babel-Xd6rGS/sh-scri= pt-61jvMa "\"1 2\" 3" | | :cmdline "1" "2" "3" | "\"1\" \"2\" \"3\"" | /tmp/babel-Xd6rGS/sh-scri= pt-61jvMa "\"1\" \"2\" \"3\"" | | header | cmdline variable value | cmdline call = | |----------------------+------------------------+--------------------------= ----------------------| | :cmdline 1 2 3 | "1 2 3" | bash -c "./sh-script-8GJz= dG 1 2 3" | | :cmdline "1 2" 3" | "\"1 2\" 3" | bash -c "./sh-script-8GJz= dG \"1 2\" 3" | | :cmdline "1" "2" "3" | "\"1\" \"2\" \"3\"" | bash -c "./sh-script-8GJz= dG \"1\" \"2\" \"3\"" | The reported bug exists because shebang+cmdline interprets the characters f= ollowing :cmdline as a *single* string. Without :shebang, a lone :cmdline = interprets them as space delimited. One possible solution is to reformat the 'process-file' ARGS for the sheban= g+cmdline case so that characters following :cmdline are interpreted as spa= ce delimited. This is possible using 'split-string-and-unquote': (split-string-and-unquote "1 2 3") -> ("1" "2" "3") (split-string-and-unquote "\"1 2\" 3") -> ("1 2" "3") (split-string-and-unquote "\"1\" \"2\" \"3\"") -> ("1" "2" "3") Whether this is a solution, in part, depends on the perennial problem of sh= ell blocks: knowing what's wrong means knowing what's right. The proposed solution assumes we intend to parse the characters following := cmdline as space delimited and grouped by quotes. However, AFAICT, the par= sing issue makes this solution ambiguous. Thoughts? -- Matt Trzcinski Emacs Org contributor (ob-shell) Learn more about Org mode at https://orgmode.org Support Org development at=C2=A0https://liberapay.com/org-mode [fn:1] AFAICT, it's due to how headers are parsed by 'org-babel-parse-heade= r-arguments' using 'org-babel-read'. The cell "\"1 2 3\"" (corresponding t= o :cmdline "1 2 3") is reduced through 'string-match' to "1 2 3". The cell= "1 2 3" (corresponding to :cmdline 1 2 3), on the other hand, passes throu= gh. The result is that :cmdline "1 2 3" and :cmdline 1 2 3 become indistin= guishable. I mention this because it's easy to get confused by this issue = which, AFAICT, is independent of the one we're trying to fix. The reported= issue appears only to be related to how the result of :cmdline header pars= ing is passed to the subprocess. ------=_Part_8939229_975561990.1713712146992 Content-Type: application/octet-stream; name=0001-testing-lisp-test-ob-shell.el-Test-shebang-cmdline-r.patch Content-Transfer-Encoding: base64 X-ZM_AttachId: 139330049469930220 Content-Disposition: attachment; filename=0001-testing-lisp-test-ob-shell.el-Test-shebang-cmdline-r.patch RnJvbSBhY2YyNzQwN2M0M2JhNDhiZTIxYjhmNzVhMWM3OTFkMmM0NWRiNTdhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXR0aGV3IFRyemNpbnNraSA8bWF0dEBleGNhbGFtdXMuY29t PgpEYXRlOiBTdW4sIDIxIEFwciAyMDI0IDE2OjAyOjQwICswMjAwClN1YmplY3Q6IFtQQVRDSCAx LzNdIHRlc3RpbmcvbGlzcC90ZXN0LW9iLXNoZWxsLmVsOiBUZXN0IHNoZWJhbmcvY21kbGluZQog cmVzdWx0cwoKKiB0ZXN0LW9iLXNoZWxsLmVsCih0ZXN0LWNtZGxpbmUtYWxvbmUtYW5kLXdpdGgt c2hlYmFuZy1oYXZlLXNhbWUtcmVzdWx0KTogVGVzdCB0aGF0CnJlc3VsdHMgd2hlbiB1c2luZyB0 aGUgY21kbGluZSBoZWFkZXIgYWxvbmUgYXJlIHRoZSBzYW1lIGFzIHdoZW4KcGFpcmVkIHdpdGgg dGhlIHNoZWJhbmcgaGVhZGVyLgotLS0KIHRlc3RpbmcvbGlzcC90ZXN0LW9iLXNoZWxsLmVsIHwg MzcgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIDEgZmlsZSBjaGFuZ2VkLCAz NyBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvdGVzdGluZy9saXNwL3Rlc3Qtb2Itc2hlbGwu ZWwgYi90ZXN0aW5nL2xpc3AvdGVzdC1vYi1zaGVsbC5lbAppbmRleCA4Y2ViZDg0NjcuLmIwYzE1 YjA3ZCAxMDA2NDQKLS0tIGEvdGVzdGluZy9saXNwL3Rlc3Qtb2Itc2hlbGwuZWwKKysrIGIvdGVz dGluZy9saXNwL3Rlc3Qtb2Itc2hlbGwuZWwKQEAgLTM2Miw2ICszNjIsNDMgQEAgZWNobyAzCiAg ICAgICAiLSAxXG4tIDJcbi0gM1xuIgogICAgICAgKGJ1ZmZlci1zdWJzdHJpbmctbm8tcHJvcGVy dGllcyAocG9pbnQpIChwb2ludC1tYXgpKSkpKSkKIAorKGVydC1kZWZ0ZXN0IHRlc3QtY21kbGlu ZS1hbG9uZS1hbmQtd2l0aC1zaGViYW5nLWhhdmUtc2FtZS1yZXN1bHQgKCkKKyAgIlBhc3MgYXJn dW1lbnRzIHRvIGEgYmxvY2suICBEb24ndCB1c2Ugc2hlYmFuZy4gIFRoZW4gdXNlCitzaGViYW5n IHNldCB0byB0aGUgc2FtZSBsYW5ndWFnZSBhcyB0aGUgYmxvY2suICBUaGUgcmVzdWx0IHNob3Vs ZAorYmUgdGhlIHNhbWUuIgorICAoc2hvdWxkIChlcXVhbAorICAgICAgICAgICAob3JnLXRlc3Qt d2l0aC10ZW1wLXRleHQKKyAgICAgICAgICAgICAgICIjK2JlZ2luX3NyYyBiYXNoIDpjbWRsaW5l IDEgMiAzCitlY2hvIFwiJDFcIgorPHBvaW50PgorIytlbmRfc3JjIgorICAgICAgICAgICAgIChv cmctYmFiZWwtZXhlY3V0ZS1zcmMtYmxvY2spKQorICAgICAgICAgICAob3JnLXRlc3Qtd2l0aC10 ZW1wLXRleHQKKyAgICAgICAgICAgICAgICIjK2JlZ2luX3NyYyBiYXNoIDpjbWRsaW5lIDEgMiAz IDpzaGViYW5nICMhL3Vzci9iaW4vZW52IGJhc2gKK2VjaG8gXCIkMVwiCis8cG9pbnQ+CisjK2Vu ZF9zcmMiCisgICAgICAgICAgICAgKG9yZy1iYWJlbC1leGVjdXRlLXNyYy1ibG9jaykpKSkpCisK KyhlcnQtZGVmdGVzdCB0ZXN0LWNtZGxpbmUtYWxvbmUtYW5kLXdpdGgtc2hlYmFuZy1oYXZlLXNh bWUtcmVzdWx0LTIgKCkKKyAgIlBhc3MgYXJndW1lbnRzIHRvIGEgYmxvY2suICBEb24ndCB1c2Ug c2hlYmFuZy4gIFRoZW4gdXNlCitzaGViYW5nIHNldCB0byB0aGUgc2FtZSBsYW5ndWFnZSBhcyB0 aGUgYmxvY2suICBUaGUgcmVzdWx0IHNob3VsZAorYmUgdGhlIHNhbWUuIgorICAoc2hvdWxkIChl cXVhbAorICAgICAgICAgICAob3JnLXRlc3Qtd2l0aC10ZW1wLXRleHQKKyAgICAgICAgICAgICAg ICIjK2JlZ2luX3NyYyBiYXNoIDpjbWRsaW5lIFwiMSAyXCIgMworZWNobyBcIiQxXCIKKzxwb2lu dD4KKyMrZW5kX3NyYyIKKyAgICAgICAgICAgICAob3JnLWJhYmVsLWV4ZWN1dGUtc3JjLWJsb2Nr KSkKKyAgICAgICAgICAgKG9yZy10ZXN0LXdpdGgtdGVtcC10ZXh0CisgICAgICAgICAgICAgICAi IytiZWdpbl9zcmMgYmFzaCA6Y21kbGluZSBcIjEgMlwiIDMgOnNoZWJhbmcgIyEvdXNyL2Jpbi9l bnYgYmFzaAorZWNobyBcIiQxXCIKKzxwb2ludD4KKyMrZW5kX3NyYyIKKyAgICAgICAgICAgICAo b3JnLWJhYmVsLWV4ZWN1dGUtc3JjLWJsb2NrKSkpKSkKKworCiAMCiA7OzsgU3RhbmRhcmQgb3V0 cHV0CiAKLS0gCjIuNDEuMAoK ------=_Part_8939229_975561990.1713712146992 Content-Type: application/octet-stream; name=0002-lisp-ob-shell.el-Add-comments-to-apply-call.patch Content-Transfer-Encoding: 7bit X-ZM_AttachId: 139330049469980000 Content-Disposition: attachment; filename=0002-lisp-ob-shell.el-Add-comments-to-apply-call.patch >From e3e71a3478666af4a4a9aa92402cd438aec52b46 Mon Sep 17 00:00:00 2001 From: Matthew Trzcinski Date: Sun, 21 Apr 2024 16:16:59 +0200 Subject: [PATCH 2/3] lisp/ob-shell.el: Add comments to `apply' call * lisp/ob-shell.el (org-babel-sh-evaluate): Comment the arguments to `apply'. These correspond to the arguments of the function it calls. Eldoc is only able to document the parameters to `apply' and not the function. --- lisp/ob-shell.el | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el index 35d9e9376..307360e3c 100644 --- a/lisp/ob-shell.el +++ b/lisp/ob-shell.el @@ -322,11 +322,11 @@ return the value of the last statement in BODY." (with-temp-buffer (with-connection-local-variables (apply #'process-file - (if shebang (file-local-name script-file) - shell-file-name) - stdin-file - (current-buffer) - nil + (if shebang (file-local-name script-file) shell-file-name) ; PROGRAM + stdin-file ; INFILE + (current-buffer) ; BUFFER + nil ; DISPLAY + ;; ARGS (if shebang (when cmdline (list cmdline)) (list shell-command-switch (concat (file-local-name script-file) " " cmdline))))) -- 2.41.0 ------=_Part_8939229_975561990.1713712146992 Content-Type: application/octet-stream; name=0003-lisp-ob-shell.el-Fix-cmdline-shebang-inconsistencies.patch Content-Transfer-Encoding: 7bit X-ZM_AttachId: 139330049469990000 Content-Disposition: attachment; filename=0003-lisp-ob-shell.el-Fix-cmdline-shebang-inconsistencies.patch >From 39e2f5ea53f8f6d86b1e4e07725a9a25ac7326ce Mon Sep 17 00:00:00 2001 From: Matthew Trzcinski Date: Sun, 21 Apr 2024 16:27:25 +0200 Subject: [PATCH 3/3] lisp/ob-shell.el: Fix :cmdline/:shebang inconsistencies * ob-shell.el (org-babel-sh-evaluate): The reported bug exists because shebang+cmdline interprets the characters following :cmdline as a single string (single argument). Without :shebang, a lone :cmdline considers the characters as being space delimited (separate arguments). This change updates the shebang+cmdline condition so that results are the same as a lone :cmdline header. Reported-by: "Max Nikulin" Link: https://list.orgmode.org/orgmode/ujamo1$5t9$1@ciao.gmane.io/ --- lisp/ob-shell.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el index 307360e3c..d379acdc6 100644 --- a/lisp/ob-shell.el +++ b/lisp/ob-shell.el @@ -327,7 +327,8 @@ return the value of the last statement in BODY." (current-buffer) ; BUFFER nil ; DISPLAY ;; ARGS - (if shebang (when cmdline (list cmdline)) + (if shebang + (when cmdline (split-string-and-unquote cmdline)) (list shell-command-switch (concat (file-local-name script-file) " " cmdline))))) (buffer-string)))) -- 2.41.0 ------=_Part_8939229_975561990.1713712146992--