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

[Greg Troxel]

Eric Schulte <address@hidden> writes:

> Greg Troxel <address@hidden> writes:
>
>> Eric Schulte <address@hidden> 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

pgpfEaDF4iJZm.pgp
Description: PGP signature