From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: [babel] how to pass data to gnuplot from another block Date: Fri, 13 Dec 2013 14:32:45 -0500 Message-ID: <87zjo4y2aq.fsf@alphaville.bos.redhat.com> References: <87d2lsbvy7.fsf@ucl.ac.uk> <87iovkihe6.fsf@gmail.com> <8738mol52h.fsf@alphaville.bos.redhat.com> <874n73gk70.fsf@gmail.com> <87vbysahv0.fsf@gmail.com> <87ob4kafjd.fsf@gmail.com> <878uvoad3s.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrYU0-0007TR-Gt for emacs-orgmode@gnu.org; Fri, 13 Dec 2013 14:33:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrYTt-0001jg-UQ for emacs-orgmode@gnu.org; Fri, 13 Dec 2013 14:33:08 -0500 Received: from plane.gmane.org ([80.91.229.3]:39145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrYTt-0001jb-No for emacs-orgmode@gnu.org; Fri, 13 Dec 2013 14:33:01 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VrYTr-0000vv-Kt for emacs-orgmode@gnu.org; Fri, 13 Dec 2013 20:32:59 +0100 Received: from nat-pool-bos-t.redhat.com ([66.187.233.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Dec 2013 20:32:59 +0100 Received: from ndokos by nat-pool-bos-t.redhat.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Dec 2013 20:32:59 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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. >> > > 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.