[Orgmode] Re: [babel] Re: org-babel-R and windows ?

[Sébastien Vauban]

Hi Dan,

Dan Davison wrote:
> Sébastien Vauban <address@hidden> writes:
>> Dan Davison wrote:
>>> "d.tchin" <address@hidden> writes:
>>>> Dan Davison <davison <at> stats.ox.ac.uk> writes:
>>>>>
>>>>> The org-babel default is to invoke R as an external shell command, and I
>>>>> think this is what is causing the problem. It requires that the emacs
>>>>> function shell-command can use the string "R" to invoke an R process,
>>>>> i.e. the R installation and the shell path must be such that this is the
>>>>> case.
>>>>
>>>> Thank you for the information and explanation. It seems that the problem
>>>> comes from the windows shell.
>>>>
>>>> I try the following :  I explicitely told emacs to use bash
>>>> with the following instructions :
>>>> (setq explicit-shell-file-name "C:/msys/1.0/bin/bash.exe")
>>>> (setq shell-file-name explicit-shell-file-name)
>>>>
>>>> It works with bash.
>>>
>>> Thanks for that, I've stored your solution in the org-babel development
>>> repo with a view to modifying our code so that these probloems are
>>> minimised in the future, and we'll also make sure the documentation
>>> addresses this.
>>
>> I'm a Windows user *and* an Ubuntu user for years, now, with one single
>> common `.emacs' file for both OS.
>>
>> Therefore, I'll show you what I have in my `.emacs':
>>
>> ;;*** ----[ 41.1 Single Shell
>>
>> ;; for single shell commands
>> (setq shell-file-name "bash")  ;; must be in the `PATH' (Windows users)
>>
>>
>> ;;*** ----[ 41.2 Interactive Shell
>>
>> ;; for the interactive (sub)shell
>> (setq explicit-shell-file-name shell-file-name)
>>
>> Almost the same, except the order (not important) and the fact that bash is
>> written in its simplest form: no hard-coded path, and no `.exe' suffix, so
>> that it works for both Win32 and Linux.
>>
>> The only thing to do, for Windows users, is ensure that `bash.exe'
>> (generally located in `C:\cygwin\bin') is in the Windows PATH environment
>> variable.
>>
>> I would advice keeping such a construct, instead of full paths.
>
> Thanks Seb,
>
> That's really helpful.

You're (more than) welcome. My goal is the same as yours: making this whole
stuff more open, more easy, more powerful, and more reliable. Do I miss
something? ;-))


> I'm really ignorant about this Windows stuff. So let me get the basics
> straight: is it the case that, if a user does *not* have a UNIX emulation
> environment installed under Windows (e.g. cygwin, msys, mingw?) then there
> is no way that org-babel external shell evaluation is going to work? Or does
> that statement need to be qualified according to language (R, shell, ruby,
> ...)? I.e., when a Windows user just has emacs and the native windows/dos
> shell, are these things just not going to work?

I have to be honest. I will give more impressions than facts, for the simple
reason that Cygwin is well implanted in my Windows, and that for more than 10
years now: I began using Emacs in 1999, and have Cygwin bundled with it since
then (as Windows is pretty useless without a better shell than `cmd.exe').

So, trying to answer your question, I would split it in two parts:

- calling scripts,
- calling applications with some data or description.

First case: script written for the shell. Without cygwin, your interpreter is
`cmd.exe', so pretty limited. And, here, we come back to one question I had
some weeks ago about which interpreter is chosen when executing the snippet:
bash, Zsh, etc. Same problem here, with a third possible command interpreter.

Second case: "applications" like R, ditaa, etc. There, I don't see any problem
for calling them with some data to feed them. The only real condition is that
the program must be found in the PATH (or the full path to the executable has
to be given).

Am I answering you in the intended way?  Do you want me to make some tests?
Don't hesitate...

Best regards,
  Seb

-- 
Sébastien Vauban