From: "Christopher M. Miles" <firstname.lastname@example.org>
To: Matt <email@example.com>
Cc: numbchild <firstname.lastname@example.org>,
Ihor Radchenko <email@example.com>,
Subject: Re: Remove "shell" as a supported Babel language within ob-shell.el
Date: Fri, 24 Mar 2023 09:53:21 +0800 [thread overview]
Message-ID: <m2y1nm2909.fsf@firstname.lastname@example.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 7199 bytes --]
At first, thanks for this long parsing and explanation.
Matt <email@example.com> writes:
> > Matt firstname.lastname@example.org> 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 something 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.
> Originally, ob-shell.el was called ob-sh.el. The main function was called `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 used for the package or the main function. That is, 'sh' refers to a specific binary and, if other binaries such as bash, dash, csh, etc. were to be supported, it would be misleading for the Babel language to refer to a specific shell, 'sh'. So, the terminology was changed to something more general, "shell". The package was renamed to "ob-shell.el", the "namespace" updated to "shell" (for example, `org-babel-execute:shell'), and the package load call changed from (sh . t) to (shell . t). This officially happened with Org 8.2 (ORG-NEWS noted the change in commit 1a9a6666dcb6d34bcbdff45445c827ed99dbf0b8, Tue Jan 21 09:52:31 2014). I think this gave people the (understandable) impression that "shell" was a valid Babel language, in addition to those listed in `org-babel-shell-names'.
> And this is where the accident happened: "shell" as a Babel language only **happens**to work. The Babel framework looks for a function prototype like "org-babel-execute:<language>". When ob-sh.el was changed to ob-shell.el, 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 concerned:
> #+begin_src shell
> echo "hello, world"
> When such a block is run, Babel looks for a function called `org-babel-execute:shell'. Running the
> block prior to Org 8.2 should have failed because no `org-babel-execute:shell' function existed. The
> name change happened to source Fri Dec 13 09:52:05 2013 in commit
> 7a6c0e35415c4a173d101336029262f3a09abb91. After the name change, the function 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
> The "shell" language specifier, as far as I can tell, was never really intentionally supported.
> Instead, it just happened to work. It happened to work because, as far back as the first
> org-babel-sh.el commit, the process buffer is created using the `shell' function. I don't know the
> history of `shell', but presently the documentation says,
> Program used comes from variable ‘explicit-shell-file-name’,
> or (if that is nil) from the ESHELL environment variable,
> or (if that is nil) from ‘shell-file-name’.
> That is, the `shell' command falls back to `shell-file-name'. I assume that `shell' has always had
> that, or a similar, fallback. The `shell-file-name' is a direct path to an executable. This means
> that when "shell" is used for the language, `shell-file-name' is called and **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 explicitly informing Emacs.
> Aside from the code change which allowed "shell" to work, "official" support of "shell" comes from
> Org manual commit 9d072ad67517875069f913315d762c9bb1e9c3ec, Sun Dec 17 11:06:05 2017 (for example,
> 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-orgmode/2013-12/msg00294.html):
> In response to the statement,
> "a coworker used "#+BEGIN_SRC shell" where he should have written "#+BEGIN_SRC sh"
> Eric says,
> "[The suggested work around] would protect against this particular error"
> Regardless of whether "shell" was intended to work as a Babel language, the fact remains that it
> does work and that it's been advertised in the manual (at least) for 6 years. What are the pros and
> cons of "shell"?
> What benefit does "shell" provide?
> - The "shell" language allows an arbitrary executable to be run. This means that shells other than
> those given in `org-babel-shell-names' can be run. People using a non-supported shell could still
> benefit from ob-shell.
> What downsides does "shell" bring?
> - "shell" falls back to `shell-file-name' which can be an arbitrary executable. Whenever I hear
> "runs an arbitrary executable", my ears perk up and I start to sweat. There may be security
This arbitrary executable fallback mechanism indeed is a con side.
> - If that executable is a shell, then the prompt gets set independently from Emacs. For the prompt
> to be filtered from the output, users would need to provide Emacs with the correct regexp. A recent
> thread discussed creating a header arg to address this:
> - 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" as 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 workflow, especially since it's
> been in the manual for 6 years. Are there any pros, cons, use-cases, or considerations I've
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:
(warn "The 'shell' language is deprecated already, use 'sh' instead.")
[ stardiviner ]
I try to make every word tell the meaning that I want to express without misunderstanding.
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2023-03-24 10:35 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-06 19:39 [PATCH] Async evaluation in ob-shell Matt
2023-02-07 11:40 ` Ihor Radchenko
2023-02-09 4:33 ` Matt
2023-02-09 11:24 ` Ihor Radchenko
2023-02-10 22:19 ` Matt
2023-02-11 11:44 ` Ihor Radchenko
2023-02-12 19:32 ` Matt
2023-02-15 15:08 ` Ihor Radchenko
2023-02-16 4:02 ` Matt
2023-02-17 10:44 ` Ihor Radchenko
2023-02-19 23:14 ` Matt
2023-02-20 11:24 ` Ihor Radchenko
2023-02-20 17:24 ` Matt
2023-02-22 10:30 ` Ihor Radchenko
2023-03-02 1:36 ` Matt
2023-03-03 14:52 ` Ihor Radchenko
2023-03-03 17:53 ` Matt
2023-03-05 12:15 ` Ihor Radchenko
2023-03-06 6:45 ` Matt
2023-03-07 12:45 ` Ihor Radchenko
2023-03-09 17:36 ` Matt
2023-03-10 1:52 ` Max Nikulin
2023-03-12 16:28 ` Jack Kamm
2023-03-18 10:48 ` Ihor Radchenko
2023-03-21 20:29 ` Matt
2023-03-22 12:12 ` Ihor Radchenko
2023-03-23 11:50 ` Ihor Radchenko
2023-03-23 19:35 ` Matt
2023-03-24 9:13 ` Ihor Radchenko
2023-03-28 2:53 ` Matt
2023-03-28 10:06 ` Ihor Radchenko
2023-04-17 15:31 ` Matt
2023-04-17 18:55 ` Ihor Radchenko
2023-04-17 18:56 ` Matt
2023-04-17 19:05 ` Ihor Radchenko
2023-03-23 3:25 ` [SUGGESTION] ob-shell async result output should not contains shell prompt Christopher M. Miles
2023-03-23 4:21 ` Matt
2023-03-23 11:12 ` Christopher M. Miles
2023-03-23 16:23 ` Matt
2023-03-24 11:20 ` Ihor Radchenko
2023-03-23 16:26 ` Remove "shell" as a supported Babel language within ob-shell.el (was Re: [SUGGESTION] ob-shell async result output should not contains shell prompt) Matt
2023-03-24 1:53 ` Christopher M. Miles [this message]
2023-03-24 11:38 ` Ihor Radchenko
2023-03-25 5:47 ` Samuel Wales
2023-03-25 18:07 ` Ihor Radchenko
2023-03-28 2:33 ` Matt
2023-02-11 20:56 ` [PATCH] Async evaluation in ob-shell jackkamm
2023-02-12 19:02 ` Matt
2023-02-13 3:16 ` Jack Kamm
2023-02-13 17:07 ` [BUG] shell sessions started outside of Babel broken Matt
2023-02-15 6:19 ` Jack Kamm
2023-02-16 12:53 ` Ihor Radchenko
2023-02-19 15:04 ` Jack Kamm
2023-02-20 11:22 ` Ihor Radchenko
2023-02-21 5:23 ` Jack Kamm
2023-02-22 10:38 ` Ihor Radchenko
2023-03-25 16:55 ` Jack Kamm
2023-03-25 16:59 ` [PATCH] Fix externally started sessions with ob-python Jack Kamm
2023-02-13 20:11 ` [BUG] conda doesn't work in ob-shell sessions Matt
2023-02-15 6:21 ` Jack Kamm
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).