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 10:48:40 -0500	[thread overview]
Message-ID: <rmiwqj84uqv.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <87vbysahv0.fsf@gmail.com> (Eric Schulte's message of "Fri, 13 Dec 2013 08:30:27 -0700")

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

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

> Greg Troxel <gdt@ir.bbn.com> writes:
>> Eric Schulte <schulte.eric@gmail.com> 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

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

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

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


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

  reply	other threads:[~2013-12-13 15:48 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 [this message]
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
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=rmiwqj84uqv.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).