[GRASS-dev] Windows-style Pathnames

[Glynn Clements]

Paul Kelly wrote:

> >> However, using / should work as an argument to fopen(). The issue is
> >> more significant if paths are constructed and stored for later use
> >> (e.g. in $GISRC). In that situation, we need to decide whether to:
> >>
> >> 1. create and store the pathname in the host's syntax, or
> >> 2. store it in Unix syntax and convert it as required.
> >
> > The above code actually does #2 under the wrong assumption that GISDBASE
> > is in an MSys installation directory.
> 
> When we are talking about host syntax or Unix syntax, do we mean only the
> difference between / and \ for directory separators in pathnames?

Mostly, although there's also the issue of drive letters and UNC
paths.

> I mean c:\grass\grassdata format is more correct, although as Glynn said
> c:/grass/grassdata works in a lot of circumstances and means very little
> in GRASS has to be changed (there are lots of C routines that form
> pathnames by concatenating strings with /). /c/grass/grassdata is
> Msys-specific and is specially interpreted by the Msys shell, right?

Right. It won't work with fopen() etc.

> I don't think there should be a need to use that format at all

Agreed.

> (except see Huidae's comment below).
> 
> >> Either option will involve a lot of changes. #1 is easier to
> >> implement, but will probably need to be done in more places (it needs
> >> to be done for every pathname which might need to be in host syntax at
> >> some point). #2 is harder, but only needs to be performed in places
> >> where host syntax is known to be necessary.
> >
> > I found #2 a better choice becase MSys shell scripts will be happier
> > with posix path.
> 
> Using the form c:/grass/grassdata rather than /c/grass/grassdata has
> proven OK for me so far (mostly in the configure script and bits of shell
> scripting done in the installation process and Makefiles). Were there many
> examples where this format was problematic?

It doesn't work with Windows command-line (console) programs, which
treat / as a switch indicator, regardless of whether or not it is
preceded by whitespace. E.g.:

	C:\>dir c:/windows
	Parameter format not correct - "windows".

	C:\>dir c:\windows
	 Volume in drive C has no label.
	 Volume Serial Number is 20AA-2D84

	 Directory of c:\windows
	...

MSys' bash accepts proper Windows pathnames, at least those which are
fully qualified, e.g.:

	sh-2.04$ ls c:\\windows\\system
	AVICAP.DLL    MCIAVI.DRV    MOUSE.DRV    SOUND.DRV   VGA.DRV       stdole.tlb
	AVIFILE.DLL   MCISEQ.DRV    MSVIDEO.DLL  SYSTEM.DRV  WFWNET.DRV
	COMMDLG.DLL   MCIWAVE.DRV   OLECLI.DLL   TAPI.DLL    WINSPOOL.DRV
	KEYBOARD.DRV  MMSYSTEM.DLL  OLESVR.DLL   TIMER.DRV   d3dx9_24.dll
	LZEXPAND.DLL  MMTASK.TSK    SHELL.DLL    VER.DLL     setup.inf

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.

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

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