i have a vague memory of having used sh and then we were told to use shell. can we all use begin src sh now?
On 3/24/23, Ihor Radchenko <yanta...@posteo.net> wrote: > Matt <m...@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> > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com