[GRASS-dev] Launching shell scripts on Windows [WAS: Windows-style
paul-grass at stjohnspoint.co.uk
Sun Nov 12 17:41:31 EST 2006
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:
> 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.
@"%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
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
More information about the grass-dev