Eric Schulte writes: > Greg Troxel writes: > >> Eric Schulte writes: >> >>>> Just an fyi: I had to set org-babel-sh-command to "bash" for this to >>>> work. Why is "sh" the default value of this variable? >>> >>> I think sh is more portable, but I guess almost any system should have >>> bash as well, I've just changed this default to bash. >> >> (Assuming you mean that you changed the default in the org sources, not >> in your config files.) >> >> Please don't, at least without discussion of the consequences of adding >> a dependency that is beyond POSIX.. sh is specified by posix, and bash >> is a) sometimes not present and b) behaves differently than as specified >> by POSIX, leading people to write nonportable code. >> >> If someone wants to run bash explicitly, it makes sense to have a bash >> language block that they can use. But the sh language block should be >> sh. The real point is that bash is a different language. > > 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). > 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. > 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. Greg