[GRASS-dev] Launching shell scripts on Windows [WAS: Windows-style Pathnames]

[Paul Kelly]

On Tue, 7 Nov 2006, Paul Kelly wrote:

> On Fri, 3 Nov 2006, Glynn Clements wrote:
>
>> Currently, a lot of GRASS assumes that scripts can be treated as
>> executables, as they are on Unix. I.e. you can call system("foo") and
>> it doesn't matter whether foo is a compiled executable or a script.
>> 
>> You can do this on Windows, but the file needs to have an extension to
>> indicate how it is run (Unix detects this from the file's header, e.g.
>> #! for scripts). The PATHEXT environment variable contains a
>> semicolon-separated list of extensions which are treated as indicating
>> an executable. On my system, it is set to:
>> 
>> 	PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH

[...]

> Unfortunately, Tcl seems to ignore the PATHEXT variable and according to 
> http://www.tcl.tk/man/tcl8.4/TclCmd/exec.htm is hardcoded to only look for 
> executable files with .com, .exe and .bat extensions. (Tcl is actually quite 
> annoying.) But that's a problem for another day (which actually might involve 
> forgetting about everything else above!).

Yes, I think so. The latest solution I've found that seems to actually 
work, is to add a one-line Windows command/batch file in the $GISBASE/bin 
directory, which runs the script in the $GISBASE/scripts directory 
(unchanged and with no special extension). A GRASS_SH environment variable 
(set in Init.sh or in a Windows-specific start-up command file) holds the 
path to the shell that needs run, and the one-line file looks like e.g. 
for g.manual.bat:

@"%GRASS_SH%" -c '"%GISBASE%/scripts/g.manual" %*'

I would have liked to use %0 to extract the name of the script to pass in 
- that would mean the contents of every .bat script would be exactly the 
same - but %0 seems to vary depending on how the script was called. 
Hard-coding the name of the script works for both command-line usage and 
from Tcl.

Also I found we can't put the .bat file in the scripts directory where 
there would be a file of the same name but without the .bat extension - if 
the scripts directory is in the path it seems Windows will try to run/open 
this file anyway in preference to the .bat file! So the solution I think 
is to put the .bat files in the bin directory and keep the scripts 
directory out of the path on Windows.

This does actually seem to work, so unless I find a major flaw or there 
are any objections I will probably commit it to CVS this week. It means we 
can remove the Msys hacks from gis.m where it invokes "sh -c" to run every 
command.

Paul