[GRASS-dev] Windows-style Pathnames

Huidae Cho grass4u at gmail.com
Thu Nov 2 06:15:09 EST 2006


On Thu, Nov 02, 2006 at 09:48:42AM +0000, Paul Kelly wrote:
> On Wed, 1 Nov 2006, Huidae Cho wrote:
> 
> >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.
> 
> But what I mean is if we avoid using this Msys-specific syntax to start with, 
> then there should be no need to transform it into proper Windows pathnames. 

Got your point.

> Where are the pathnames that you need to transform to Windows syntax being 
> generated from?

Nothing comes up in my mind at the moment.

> 
> >>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.
> 
> Good point. Perhaps there is an Msys command that can convert paths to Msys 
> format before including them in the PATH?

AFAIK, there are no converters for that.  PATH was just an example.

> I feel though that this is a very specific problem with scripts changing the 
> PATH and not worth changing the behaviour of the rest of GRASS just for it.
> 
> >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.
> 
> Not sure what you mean about implementing "which" using $FOO?

See #5 in SUBMITTING_SCRIPTS.  What I mean is if we accept Windows-style
path names, scripts should deal with both POSIX (/) and Windows (:, \)
path names in some (maybe few?) cases.

> How big a problem do you think this is? I would hazard a guess that in most 

I don't think this is a big problem.  I'm wondering how many shell/GRASS
variables actually store absolute paths.  Probably, only GISDBASE in
GISRC?  As Hamish pointed out, since the data stores path names with /
separator, c:/ is probably better than c:\?

Huidae

> cases Msys/Unix commands used in scripts will work OK with c:/grass/grassdata 
> style paths used throughout. How many scripts set the PATH? Are there standard 
> Msys functions or commands for converting a path between formats that we could 
> use in some way?
> 
> Paul




More information about the grass-dev mailing list