[GRASS-dev] Windows-style Pathnames

[Paul Kelly]

On Fri, 3 Nov 2006, Glynn Clements wrote:

>
> Paul Kelly wrote:
>
>>> Note that the backslash is a shell metacharacter, so it will have to
>>> be protected from interpretation if it appears directly in a script or
>>> user input.
>>
>> For that reason alone, perhaps easiest to use c:/grass/grassdata format as
>> much as possible, at least as an interim measure?
>
> Maybe. We'll need to convert it for e.g. system().

Yes. The way I've done that in the is first to pass the string containing 
the path to G_convert_dirseps_to_host(), which will replace all occurences 
of / by \, and then quote the path name with \"escaped double quotes\" 
within the argument supplied to system() - I think this should cover both 
eventualities of the pathname containing spaces, *and* the backslashes 
possibly being misinterpreted by a shell. Although as we've seen it should 
normally by cmd.exe invoked for this.

>> OK but whether we use c:/ or c:\ we still have the same problem with
>> setting the PATH in scripts Huidae was talking about. But it remains to be
>> seen how big a problem it is I guess.
>
> Most scripts don't set PATH.

Yes I think the only example I've seen is the HTML documentation 
generation thing in the Makefiles and that is easily handled as it's done 
within Msys and using Msys-style paths anyway.

> For a native Windows version, I would be strongly in favour of
> replacing init.sh with a Windows command file. Actually, if users only
> need to use gis.m, it should be possible to start it as a GUI
> application without cmd.exe, bash or a console ever getting involved.

Yes I agree. But a batch/command file that sets the appropriate 
environment variables and prompt to run command-line GRASS from a cmd.exe 
shell would also be a nice touch to include, especially if we get display 
drivers working.

>> And it should be possible for a user to run the scripts if
>> necessary using another shell, not necessarily the Msys one? Perhaps
>> determined by a GRASS_SH environment variable.
>
> 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
>
> If you execute a "command" without a directory or extension, Windows
> will consider files with any of those extensions when trying to
> resolve the command name to an executable, effectively doing:
>
> 	for dir in $PATH ; do
> 	  for ext in $PATHEXT ; do
> 	    if [ -f $dir/$cmd$ext] ; then
> 	      exec $dir/$cmd$ext
> 	    fi
> 	  done
> 	done
>
> AFAICT, the "interpreter" is selected according the registry entry
> corresponding to the extension, the same as if you had double-clicked
> on the file's icon from an Explorer window.
>
> So, if we were to add ".sh" extensions to all of the scripts, and add
> ".sh" to PATHEXT, calling e.g. system("r.out.gdal ...") should run
> r.out.gdal.sh using the program associated with ".sh" in the registry.

That sounds like a fairly handy way of doing it. Does the installing user 
need to be an administator on the Windows machine to change the registry 
to do this file extension association?

Or the other way that was discussed before was some kind of launcher 
executable program. I was thinking that it could even be installed instead 
of all the scripts like "front.end" used to be, and it would check the 
contents of the real scripts and start them with the shell specified in a 
GRASS_SH environment variable. But that might be a bit complicated and 
prone to going wrong whereas the first approach would be more 
understandable for experienced Windows users.