From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [babel] how to pass data to gnuplot from another block Date: Fri, 13 Dec 2013 23:40:13 +0100 Message-ID: <87a9g4z86q.fsf@Rainer.invalid> 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]:36063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrbPO-0006yW-DX for emacs-orgmode@gnu.org; Fri, 13 Dec 2013 17:40:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrbPI-0006Jz-AY for emacs-orgmode@gnu.org; Fri, 13 Dec 2013 17:40:34 -0500 Received: from plane.gmane.org ([80.91.229.3]:60122) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrbPG-0006JP-Rs for emacs-orgmode@gnu.org; Fri, 13 Dec 2013 17:40:27 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VrbPF-0006g4-0V for emacs-orgmode@gnu.org; Fri, 13 Dec 2013 23:40:25 +0100 Received: from pd9eb1fe9.dip0.t-ipconnect.de ([217.235.31.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Dec 2013 23:40:25 +0100 Received: from Stromeko by pd9eb1fe9.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Dec 2013 23:40:25 +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. 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 up. > 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). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds