emacs-orgmode
[Top][All Lists]
Advanced

[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: Nick Dokos
Subject: Re: [O] [babel] how to pass data to gnuplot from another block
Date: Fri, 13 Dec 2013 14:32:45 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Eric Schulte <address@hidden> 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.
>>
>
> 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?
>
>

Since I'm the de facto instigator of the original change in the default,
let me add my 2 cents. I'm fine with this change (or without it). I'd be
fine with changing the org-babel-sh-command setting in my config and
leaving the default alone.

And I sympathize with Greg's wish for portability in general, although
imo it's not particularly important in this case (ducking and donning
my asbestos underwear here).

I write short scripts in org files to document some process: I can't
remember anything any longer, so putting the details in a file is the
only way for me to figure out what I did six months (or even two days)
ago (finding the file again two days hence is another matter...) In most
cases, what I put in there is some sequence of commands, which will be
interpreted correctly no matter which shell is used.  If I have anything
more complicated (non-trivial control flow, non-trivial i/o redirection,
etc etc), I put it in a script in ~/bin and invoke that in the source
code block. I may not be typical here of course, but that's why I think
that portability is not particularly important in this case - so leave
the default at sh and be done with it.

But when I tried and failed to run Eric's script in the original email,
I had to do a little digging to figure out what went wrong and how to
fix it (I don't remember running across org-babel-sh-command before
this). So I asked the question about sh and the rest is history. I
probably should have made the observation that org-babel-sh-command had
to be modified to run the code block (which was plainly true) and left
the question (which could be interpreted in various ways) out. OTOH,
there is now this discussion and presumably the end result will be
better than what we started with.

Nick

PS. I haven't tried out the patch but I plan to do so over the weekend.






reply via email to

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