From: Ihor Radchenko <yantar92@posteo.net>
To: Matt <matt@excalamus.com>
Cc: numbchild <numbchild@gmail.com>, emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Remove "shell" as a supported Babel language within ob-shell.el (was Re: [SUGGESTION] ob-shell async result output should not contains shell prompt)
Date: Fri, 24 Mar 2023 11:38:58 +0000 [thread overview]
Message-ID: <87h6uaxtt9.fsf@localhost> (raw)
In-Reply-To: <1870f4aeb76.12af86c2f745535.7020028564160040455@excalamus.com>
Matt <matt@excalamus.com> writes:
> 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 considerations.
> - 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: 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" 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 overlooked?
I would not see arbitrary executable to be such a big deal. At the end,
if SHELL is set to something fishy, the user is likely in serious
trouble anyway. SHELL is a part POSIX standard at the end.
Yet, the problem with unsupported shells is indeed real.
Moreover, "shell" code blocks are currently not portable to different
environments.
I suggest the following:
1. Introduce a new customization `org-babel-default-shell', defaulting
to (or (executable-find "sh") (executable-find "cmd.exe")).
2. Use the value as default shell in "shell" code blocks.
3. Document and announce the change.
4. Create org-lint checker that will mark "shell" code blocks as not
desired.
The above steps will ensure minimal breakage for existing uses of
"shell" blocks. Only users who wrote shell blocks for non-standard shell
will have to adapt.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2023-03-24 15:45 UTC|newest]
Thread overview: 72+ 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 ` Remove "shell" as a supported Babel language within ob-shell.el Christopher M. Miles
2023-03-24 11:38 ` Ihor Radchenko [this message]
2023-03-25 5:47 ` Remove "shell" as a supported Babel language within ob-shell.el (was Re: [SUGGESTION] ob-shell async result output should not contains shell prompt) 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
2024-01-18 11:55 ` Ihor Radchenko
2024-01-21 22:48 ` Jack Kamm
2024-01-22 3:42 ` Jack Kamm
2024-01-22 11:59 ` Ihor Radchenko
2024-01-23 6:09 ` Jack Kamm
2024-01-24 15:22 ` Ihor Radchenko
2024-01-25 19:14 ` Matt
2024-01-25 20:36 ` Ihor Radchenko
2024-01-26 0:42 ` Jack Kamm
2024-01-27 10:25 ` Matt
2024-02-09 16:37 ` Ihor Radchenko
2024-01-23 18:51 ` Suhail Singh
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6uaxtt9.fsf@localhost \
--to=yantar92@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=matt@excalamus.com \
--cc=numbchild@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).