[GRASS-dev] Windows-style Pathnames

[Glynn Clements]

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().

> > The biggest problem with scripts is when MSys decides to be "clever"
> > and do automatic translation. IMHO, we would be better off using host
> > syntax throughout.
> 
> 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.

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.

> > So far as I'm concerned, the "Windows" version
> > should be just that, and not an "MSys" version. If people can live
> > without the contents of the scripts directory, it shouldn't be
> > necessary for end users to even have MSys.
> 
> Yes. I thought that but wasn't sure. So Msys and MinGW are needed only for 
> compilation?

MSys is needed for shell scripts, of which there are currently a fair
number.

> 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.

> And it's the shell's 
> responsibility to make sure that the various Unix commands work OK when 
> called from within its environment then. Am I making sense?

Well, a Bourne-shell script needs a Bourne-compatible shell to run. 
However, the main job of a shell is to run external commands. The
arguments to those commands may be generated (or hard-coded) within
the shell, or passed to the shell as arguments. Most of the time, the
shell is just passing strings around. If it gets a filename from one
program and passes it to another, both programs have to be using the
same syntax.

Windows programs will always use Windows syntax. We get to choose the
syntax used by GRASS programs. If MSys uses Unix syntax, either MSys
will either have to convert it, or the script will. AFAICT, MSys
converts environment variables to Windows syntax, and converts
pathnames to half-way syntax (with a forward slash, e.g. c:/windows)
when it recognises that it's passing a pathname to an external
command, but there are cases where Unix syntax doesn't get converted.

-- 
Glynn Clements <glynn at gclements.plus.com>