[GRASS-dev] Windows-style Pathnames
Glynn Clements
glynn at gclements.plus.com
Wed Nov 1 21:05:00 EST 2006
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>
More information about the grass-dev
mailing list