[GRASS-dev] Windows-style Pathnames
paul-grass at stjohnspoint.co.uk
Mon Nov 6 17:34:36 EST 2006
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
>> 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:
> 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
> 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.
More information about the grass-dev