[GRASS-dev] Windows-style Pathnames

[Huidae Cho]

On Wed, Nov 01, 2006 at 10:54:09PM +0000, Paul D Kelly wrote:
> On Wed, 1 Nov 2006, Glynn Clements wrote:
> 
> >Windows isn't Unix. There will inevitably need to be some handling of
> >platform-specific behaviour.
> >However, it's far better to create a set of functions to handle such
> >issues than to deal with individual files separately.
> 
> Yes I agree with that; I think that's what I was trying to say but hadn't
> thought it through. E.g. a G_mkdir() to abstract the fact that Unix and
> Windows mkdir() require a different number of arguments, that kind of
> thing.
> 
> 
> On Wed, 1 Nov 2006, Huidae Cho wrote:
> 
> >On Wed, Nov 01, 2006 at 09:25:22PM +0000, Glynn Clements wrote:
> >>>-#ifdef __MINGW32__
> >>>-       sprintf ( buf, "%s\\%s\\VAR", G_location_path(), G_mapset() );
> >>>-#else
> >>>         sprintf ( buf, "%s/%s/VAR", G_location_path(), G_mapset() );
> >>>-#endif
> >>This is arguably correct, although possbily better formulated as e.g.:
> >>	sprintf ( buf, "%s" DIRSEP "%s" DIRSEP "VAR", G_location_path(), G_mapset() 
> >>);
> >>or:
> >>	sprintf ( buf, "%s%s%s%sVAR", G_location_path(), DIRSEP, G_mapset(), DIRSEP 
> >>);
> >>rather than using a platform test.
> >>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?
> 

No.  MSys has a virtual root to wherever it is installed, so /usr/...
should be transformed to something like c:\msys\1.0\usr\...  I doubt we
can completely avoid using this convention in winGRASS.

> 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? I don't think there should be a 
> need to use that format at all (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?

One example is $PATH.  '<DRIVE>:' cannot be used in PATH because ':' is
already used for path separators in the MSys environment.  For example,
exporting "PATH=c:/grass/bin:c:/msys/bin" in a shell script is
problematic while setting "PATH=c:/grass/bin;c:/msys/bin" (note ';'
separator) in a batch file (e.g., c:\msys\1.0\msys.bat) is OK since MSys
takes care of converting it to PATH=/c/grass/bin:/c/msys/bin.

The Windows-style path causes another problem/inconvenience when it
comes to shell scripting because scripts have to deal with two types of
path styles in some cases.  For example, it would be complicated to
implement "which" using $FOO if the script reads in a config file
directly.  For this reason, I prefer UNIX-style pathnames even if host
syntax looks more reasonable.

Huidae

> 
> Paul
>