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

[Greg Troxel <gdt@ir.bbn.com>]

[-- Attachment #1: Type: text/plain, Size: 3048 bytes --]


Eric Schulte <schulte.eric@gmail.com> writes:

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

I see your point.  But stepping back, I have always felt that
"#+begin_src foo" referred to a language, sometimes where that language
and a particular program are inseparable (e.g. gnuplot).  But sh is a
first-class language.

> See the first line in ob-sh.el,
> ,----
> | ;;; ob-sh.el --- org-babel functions for shell evaluation
> `----

Sure, but that's just repeated the ambiguity :-)

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

For shell, I see that there are two concepts to detangle:

  a shell is a particular command interpreter, particularly useful for
  humans

  there are multiple shell languages, but far fewer than the number of
  interpreters.


For languages, I see

   POSIX sh
   the bash flavor of POSIX sh
   csh

While bash and POSIX sh are close, csh isn't at all close, and is only
similar in that people also use it for a shell.


In an org document, I think it's better if the result depends less on
variables not set in the document.   So a code block in a document is
really written in some language.  And it therefore makes sense to
specify that in the begin_src wrapper.

I don't see that there is any call for csh, as the received wisdom is
that one shouldn't write scripts in it (at least in modern times).  (It
was originally a BSD thing, and BSD culture is very much POSIX sh now.)

So separately from how the lisp works, I would favor

  #+begin_src sh     # posix sh
  #+begin_src bash   # bash (leaving version ambiguous??)
  #+begin_src csh     # csh, but not sure there's a need


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

Are you aware of any significant use of "zsh scripts"?  I see that as
POSIX sh, with spiffy user-facing features.
> 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.

Thanks.  It's good to be having the larger discussion first.

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

I forgot about "&>", even though I type it all the time interactively
but I'm pretty careful in scripts :-)

Thanks,
Greg

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]