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
specified.
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.
Best,
>
> Greg
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D
next prev parent 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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 \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).