[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Achim Gratz
Subject: Re: [O] [babel] how to pass data to gnuplot from another block
Date: Fri, 13 Dec 2013 23:40:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Eric Schulte writes:
>> 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.

I've also seen ksh, mksh, posh (the latter specifically for POSIX
compatibility checks).  But trying to enumerate all possible shell names
is futile, especially when the same shell dialect can have different
names on different systems and you'll only find a handful of those on
each particular system installed.  Then there are those systems where at
least two different shells exist with the same name in different paths
and you'll get one or the other depending on which way your path is set

> The attached patches make this change and continue to pass the entire
> test suite.  The problem being that with ob-sh, no longer present many
> users may have to change their configuration and possible the value of
> their local.mk file.  One solution there is to add a dummy ob-sh.el with
> a deprecation message for some transition time.  Thoughts?

I'm not sure this does the right thing (if that is even possible in this
case).  It looks overcomplicated to me, anyway.

There are two sides to a shell: the programming language / scripting
part and the interactive part.  Of those shells that are somewhat POSIX
compatible, the programming language part isn't all that much different
(at least no more than, say, different C dialects).  Even csh does the
right thing with a lot of POSIX stuff and you shouldn't really use it
for serious scripting anyway.  The interactive part shouldn't really
figure into Babel, even though the particular choice will introduce one
or the other quirk in certain areas of scripting if you're not careful.

Emacs' shell-mode recognizes that ambiguity: it looks up the bang line
to decide which dialect to chose and waits for a user decision if it
can't find one.  I'd have no problem if ob-sh did the same and simply
ran with whatever it can get away with (assuming close-enough-to-POSIX)
and only chose a specific shell when asked (via bang line or otherwise).

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]