From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id YDKsIPd8HWSjmgAASxT56A (envelope-from ) for ; Fri, 24 Mar 2023 11:35:35 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id QN6sIPd8HWTPlgAA9RJhRA (envelope-from ) for ; Fri, 24 Mar 2023 11:35:35 +0100 Received: from lists.gnu.org (unknown [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 E6DBD387D8 for ; Fri, 24 Mar 2023 11:35:29 +0100 (CET) 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=1679654130; h=from:from:sender:sender:reply-to: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; bh=rqO1FxcQ/+MFgwucQF9pYoJlmtjfxOGVTWbxPM4OH/M=; b=RIbSVt6AskKkR1hYsWB0PiivCglJPdR/uXIV+VFF3G4XHoAAjBAkuO6TT6RnTmOnYqwzMR paFxongThm21cPbkRMJfv2TTSqfz6ZPPhm9BQ6Cfzdg71vT3fO1fpCPl76RqJts6jV/OLs LwLnLnIToOCDivUSJDGmlJS45nINxWnWGdUf2fZxSHgGIIhCVWDiGAPU8kg5WBpyBT5SWG NV2exAlytYZvv93+ZB9Nt95ZDhxaWqFwHrjn4/FvyJX+ysPrMpJWPrmNcYseAyQyOayqRf iL5LGvrV8wHspoKC+6TEqrs3zLP2d7BayYwv2IRnbUjvjM0SLaLm/MhRqQKSZQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1679654130; a=rsa-sha256; cv=none; b=YmOsXNK38Cj37ZoN7dt1MJLseoSgGxKo6mb1+J118KOpVYFDtpyIONbyK57mDw05ZQdfM3 iP9gcCubLXOshce0BbRFHKu308D7CCS3gHpx550sG/EeNe4+5C3bvzxvocucbjRuePAkmx qOETib0BnN6ubhgKChLsQkQkonjvU+xOTmQ2KVArWT7tYAF5TXt6GvERYUTyak8ytSnGCh MmVUOG9Z93c/krbUwbaGl36oC6yJiAfCddNdcsSkRwKum16QxRdg11wAqWsXpWZef2w0dH FgJqVgQpxqdjii8468g6GXD+cGvOTGffnk5dTniTcmMPLOgSjp5IW3uoQZkdAA== 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 localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pfWuq-0000iQ-A7; Thu, 23 Mar 2023 22:12:28 -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 1pfWuo-0000iC-Cp for emacs-orgmode@gnu.org; Thu, 23 Mar 2023 22:12:26 -0400 Received: from [2409:8a28:6032:c080:52d2:f5ff:fe16:c591] (helo=Mac-mini.local) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pfWuN-0000Wo-RE for emacs-orgmode@gnu.org; Thu, 23 Mar 2023 22:12:26 -0400 Received: by Mac-mini.local (Postfix, from userid 501) id 5EF0282836A0; Fri, 24 Mar 2023 10:11:51 +0800 (CST) References: <186283d230a.129f5feb61660123.3289004102603503414@excalamus.com> <87v8kd8zzw.fsf@localhost> <1863472efe9.10fdd5ba4258906.5972264927968042941@excalamus.com> <87y1p7axpe.fsf@localhost> <1870cb30c41.ba75a358545366.6275787333945468963@excalamus.com> <1870f4aeb76.12af86c2f745535.7020028564160040455@excalamus.com> User-agent: mu4e 1.8.14; emacs 30.0.50 From: "Christopher M. Miles" To: Matt Cc: numbchild , Ihor Radchenko , emacs-orgmode Subject: Re: Remove "shell" as a supported Babel language within ob-shell.el Date: Fri, 24 Mar 2023 09:53:21 +0800 In-reply-to: <1870f4aeb76.12af86c2f745535.7020028564160040455@excalamus.com> Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:8a28:6032:c080:52d2:f5ff:fe16:c591 (deferred) Received-SPF: softfail client-ip=2409:8a28:6032:c080:52d2:f5ff:fe16:c591; envelope-from=numbchild@gmail.com; helo=Mac-mini.local X-Spam_score_int: 25 X-Spam_score: 2.5 X-Spam_bar: ++ X-Spam_report: (2.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, MSGID_MULTIPLE_AT=1, NML_ADSP_CUSTOM_MED=0.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, SPOOFED_FREEMAIL_NO_RDNS=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." List-Unsubscribe: , List-Archive: List-Post: List-Help: X-Migadu-Queue-Id: E6DBD387D8 X-Spam-Score: -2.64 X-Migadu-Spam-Score: -2.64 X-Migadu-Scanner: scn0.migadu.com List-Subscribe: , Reply-To: numbchild@gmail.com 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-TUID: XY+g3Dpho0uH --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable At first, thanks for this long parsing and explanation. Matt writes: > > Matt matt@excalamus.com> writes: > > > > > Is there a reason you're using "shell" instead of one of the shells = listed in `org-babel-shell-names'? > > I'm still curious why you're using "shell". I want to know if it's somet= hing you're using for a specific reason. There's no wrong answer! > > I ask because I have an agenda: as far as I can tell, "shell" as a Babel = language is a historical accident.=20=20 > > #+begin_longwinded_explanation > Originally, ob-shell.el was called ob-sh.el. The main function was calle= d `org-babel-execute:sh' and only /usr/bin/env sh was supported. Over time= it became clear that to support other shells, the "sh" name shouldn't be u= sed for the package or the main function. That is, 'sh' refers to a specif= ic binary and, if other binaries such as bash, dash, csh, etc. were to be s= upported, it would be misleading for the Babel language to refer to a speci= fic shell, 'sh'. So, the terminology was changed to something more general= , "shell". The package was renamed to "ob-shell.el", the "namespace" updat= ed to "shell" (for example, `org-babel-execute:shell'), and the package loa= d call changed from (sh . t) to (shell . t). This officially happened with= Org 8.2 (ORG-NEWS noted the change in commit 1a9a6666dcb6d34bcbdff45445c82= 7ed99dbf0b8, Tue Jan 21 09:52:31 2014). I think this gave people the (unde= rstandable) impression that "shell" was a valid Babel language, in addition= to those listed in `org-babel-shell-names'.=20=20 > > And this is where the accident happened: "shell" as a Babel language only= **happens**to work. The Babel framework looks for a function prototype li= ke "org-babel-execute:". When ob-sh.el was changed to ob-shell.e= l, the function `org-babel-execute:sh' became `org-babel-execute:shell'. = A call like follows is perfectly legal as far as the Babel framework is con= cerned: > > #+begin_src shell > echo "hello, world" > #+end_src > > When such a block is run, Babel looks for a function called `org-babel-ex= ecute:shell'. Running the > block prior to Org 8.2 should have failed because no `org-babel-execute:s= hell' function existed. The > name change happened to source Fri Dec 13 09:52:05 2013 in commit > 7a6c0e35415c4a173d101336029262f3a09abb91. After the name change, the func= tion existed and a block > using "shell" would execute! Yes, I originally use "sh" too. But at some time point, I saw an article somewhere, then I switched to "shell". I forget the specific reason already. > The "shell" language specifier, as far as I can tell, was never really in= tentionally supported. > Instead, it just happened to work. It happened to work because, as far ba= ck as the first > org-babel-sh.el commit, the process buffer is created using the `shell' f= unction. I don't know the > history of `shell', but presently the documentation says, > > Program used comes from variable =E2=80=98explicit-shell-file-name=E2=80= =99, > or (if that is nil) from the ESHELL environment variable, > or (if that is nil) from =E2=80=98shell-file-name=E2=80=99. > > That is, the `shell' command falls back to `shell-file-name'. I assume th= at `shell' has always had > that, or a similar, fallback. The `shell-file-name' is a direct path to a= n executable. This means > that when "shell" is used for the language, `shell-file-name' is called a= nd **any** startup script, > such as .bash_profile or .bashrc, is called. The prompt could be set to *= *anything** and Emacs will > never know, and can never know, what the prompt is without the user expli= citly informing Emacs. > > Aside from the code change which allowed "shell" to work, "official" supp= ort of "shell" comes from > Org manual commit 9d072ad67517875069f913315d762c9bb1e9c3ec, Sun Dec 17 11= :06:05 2017 (for example, > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/doc/org-manual.= org?id=3Df7aa8c19f5170dbf09538686fb569f9b60acbd6c#n18410). > This appears unconnected with the code change. The addition to the manual= happened 4 years after the > code name change and none of the commit messages around the time of code = change suggest that "shell" > was intended to work as a language. In fact, I found this email from Eric= Schulte (creator of Babel > and maintainer at the time of the code change) which suggests that "shell= " is in fact not supported > or intented as a language (https://lists.gnu.org/archive/html/emacs-orgmo= de/2013-12/msg00294.html): > > In response to the statement, > > "a coworker used "#+BEGIN_SRC shell" where he should have written "#+BEGI= N_SRC sh" > > Eric says, > > "[The suggested work around] would protect against this particular error" > > #+end_longwinded_explanation > > Regardless of whether "shell" was intended to work as a Babel language, t= he fact remains that it > does work and that it's been advertised in the manual (at least) for 6 ye= ars. What are the pros and > cons of "shell"? > > What benefit does "shell" provide? > > - The "shell" language allows an arbitrary executable to be run. This mea= ns that shells other than > those given in `org-babel-shell-names' can be run. People using a non-sup= ported shell could still > benefit from ob-shell. > > What downsides does "shell" bring? > > - "shell" falls back to `shell-file-name' which can be an arbitrary execu= table. Whenever I hear > "runs an arbitrary executable", my ears perk up and I start to sweat. The= re may be security > considerations. This arbitrary executable fallback mechanism indeed is a con side. > - If that executable is a shell, then the prompt gets set independently f= rom Emacs. For the prompt > to be filtered from the output, users would need to provide Emacs with th= e correct regexp. A recent > thread discussed creating a header arg to address this: > https://list.orgmode.org/87ttzgeg3w.fsf@localhost/ > - We would get bug reports about non-supported shells which kind of work,= but have issues because they're not supported > - Maintence associated with supporting arbitrary (shell) executables > > As the current maintainer of ob-shell, I'm in favor of removing "shell" a= s a Babel language. The > cons appear to far outweigh the pros. However, I'm aware others may have = good use for it. It's been > a part of Org for nearly a decade. I'm sure it's part of people's workflo= w, especially since it's > been in the manual for 6 years. Are there any pros, cons, use-cases, or c= onsiderations I've > overlooked? If the "shell" language will be removed, I'm ok with that. I hope this library can warn user "shell" is deprecated. Because I have a lot of already written Org mode files using "shell" as source block language. Replacing it with command-line tools like "sed" etc is ok. Like adding a line warning code: #+begin_src emacs-lisp (warn "The 'shell' language is deprecated already, use 'sh' instead.") #+end_src =2D-=20 [ stardiviner ] I try to make every word tell the meaning that I want to express without mi= sunderstanding. Blog: https://stardiviner.github.io/ IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAmQdBuYACgkQG13xyVro msMAdggAjBJayk7cmSHJy2Mgudn2VYdrIvwDxsQDXihcYa5m+b3Tz4noIV5+jQG5 9DSWAOBXUdVoLmQe0nlPzrGPw2Hui1sYsJ5FGDFgFhm3TmAoY3RpmiAJWx3qCku4 EfE1f0MvXxVgkFSCp+wZlJXiXxL1rGN4+YO7f70bwqJtpJ6l/gFZWnBW2+390fEd W02Xxh4jYbKZq5ikRk+vNvgLCFDPmz27kREo0kwCXn0aZRQqFpF1oqwZy+tW1Y0p KuHmp8LnmadZa8c04J1nVSiBRHom0TlkzIU/GwyTxssVQbHFOpilU6JmuB1ElBu3 6xm9hLiEB0E4HYCiVLMV0ybx4E327w== =jRaC -----END PGP SIGNATURE----- --=-=-=--