emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Greg Troxel <gdt@ir.bbn.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Nick Dokos <ndokos@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: [babel] how to pass data to gnuplot from another block
Date: Fri, 13 Dec 2013 13:38:57 -0500	[thread overview]
Message-ID: <rmibo0k4mv2.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <87ob4kafjd.fsf@gmail.com> (Eric Schulte's message of "Fri, 13 Dec 2013 09:20:38 -0700")

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

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

For languages, I see

   POSIX sh
   the bash flavor of POSIX sh

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


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

  parent reply	other threads:[~2013-12-13 18:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-22  9:57 [babel] how to pass data to gnuplot from another block Eric S Fraga
2013-11-22 15:00 ` Eric Schulte
2013-11-22 17:27   ` Nick Dokos
2013-11-23 16:15     ` Eric Schulte
2013-12-13 15:23       ` Greg Troxel
2013-12-13 15:30         ` Eric Schulte
2013-12-13 15:48           ` Greg Troxel
2013-12-13 16:20             ` Eric Schulte
2013-12-13 17:13               ` Eric Schulte
2013-12-13 19:32                 ` Nick Dokos
2013-12-13 22:40                 ` Achim Gratz
2013-12-13 23:18                 ` Eric Schulte
2013-12-14 10:21                   ` Achim Gratz
2013-12-13 18:38               ` Greg Troxel [this message]
2013-12-13 19:08                 ` Sebastien Vauban
2013-12-13 16:32           ` Achim Gratz
2013-12-05  7:35   ` Eric S Fraga
2013-12-05 18:29     ` Eric Schulte
2013-12-05 19:59       ` Eric S Fraga
2013-12-06  2:06         ` Eric Schulte
2013-12-06 11:59           ` Eric S Fraga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=rmibo0k4mv2.fsf@fnord.ir.bbn.com \
    --to=gdt@ir.bbn.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=ndokos@gmail.com \
    --cc=schulte.eric@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).