emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eric Schulte <schulte.eric@gmail.com>
To: Greg Troxel <gdt@ir.bbn.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 09:20:38 -0700	[thread overview]
Message-ID: <87ob4kafjd.fsf@gmail.com> (raw)
In-Reply-To: <rmiwqj84uqv.fsf@fnord.ir.bbn.com> (Greg Troxel's message of "Fri, 13 Dec 2013 10:48:40 -0500")

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

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.


> Greg

Eric Schulte
PGP: 0x614CA05D

  reply	other threads:[~2013-12-13 16:22 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 [this message]
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
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=87ob4kafjd.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=gdt@ir.bbn.com \
    --cc=ndokos@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).