Re: [babel] how to pass data to gnuplot from another block

[Eric Schulte <schulte.eric@gmail.com>]

>>
>> 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