>> >> I understand your point, but in reality I doubt there are many systems >> on which people use Org-mode with code blocks and on which sh is >> available but no bash is installed. > > That may be true on some flavors of Linux, but on BSDs: > > bash is not the normal shell (and is not part of the base system, at > least on NetBSD, and I think that's still true on the others). When > it does exist it's not in /bin. > > It's not so odd to have a system without bash. > > I am also under the impression that Debian does not use bash as the > /bin/sh. > > org, like anything else, should be OS-agnostic, and follow open > standards whenever that's at all reasonable. > >> Bash is the new normal shell and I would argue is what most users expect >> from a shell code block. > > I find that pretty astounding. In a block labeled sh it is obvious that > a shell conforming to the POSIX sh standard is expected, and it's not so > different from a file with "#!/bin/sh". Users who expect bash in a > block labeled sh are wrong, although I agree that many people have been > misled this way by the culture of using "test ==" in a file that starts > #!/bin/sh. > > The real issue is that org files that actually expect bash (test ==, > etc.) become nonportable to other environments. If someone is writing > a script and not intending to use beyond-posix features, it's harmful to > let them work (in cases where they are published). >
Points well made, I was not aware of the BSD default. Although purely semantically, in my opinion the "sh" in "#+begin_src sh" indicates generic "shell-script", not the POSIX sh. E.g., there is no ob-bash.el or ob-csh.el. See the first line in ob-sh.el, ,---- | ;;; ob-sh.el --- org-babel functions for shell evaluation `---- > >> E.g., the default value of `shell-file-name' used by M-x shell is >> "/bin/bash". > > I just checked on my system (NetBSD 6 i386, emacs 23.4.1), and > shell-file-name is documented to inherit from SHELL if present, which it > does. It's /bin/sh if SHELL is unset, which complies with the > documentation: > > *File name to load inferior shells from. > Initialized from the SHELL environment variable, or to a system-dependent > default if SHELL is not set. > > which doesn't promise bash (or even a Bourne-style shell!). (The emacs > package doesn't depend on the bash package.) But shell-file-name is > about giving the user of emacs their shell, not using a particular > programming language, so this fuzz is fine. > And this is where we disagree. Sh code blocks don't currently promise POSIX sh, they promise a shell. This is certainly a much more dangerous generalization than say Perl code blocks possibly using Perl 5 or 6. How about the following resolution? We rename ob-sh.el to ob-shell.el. New "shell" code blocks could use the value of the `org-babel-sh-command' environment variable. Then sh, bash, zsh, csh, ash, dash (am I missing any other common ones) use the specific shell specified. What do you think? In the mean time, I don't believe the change in default value for `org-babel-sh-command' has been included in any maintenance releases, so I've just reverted this to minimize any further confusion. > >> It is possible to explicitly set shell code blocks to use sh. > > Sure, but that wasn't my point; it's the encouragement of nonportability > that is problematic. > > I should point out that I'm not a bash hater --- I actually use it as my > interactive shell, and have done so since around 1990. But I don't > write scripts in it. > And I should say that I've argued the same point your making myself in the past (on a project making the much more serious error of using bash notation ">&" in a shell script starting with "#!/bin/sh"). I think we only disagree on the current meaning of "sh" in code blocks, which hopefully the suggestion above will rectify. Best, > > Greg -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
