[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