[GRASS-windows] native grass63RC4 and MSYS shell

[Glynn Clements]

Moritz Lennert wrote:

> > AFAIK, starting GRASS or running GRASS commands from the MSys shell is
> > unsupported under Windows.
> 
> No, it should work. I cannot reproduce the above error messages. 
> However, to make the current 63RC4 package work, you have to change the 
> bin/grass63 file from
> 
> GISBASE=c:/grass63RC4/grass-6.3.0RC4
> 
> to
> 
> GISBASE=/c/grass63RC4/grass-6.3.0RC4
> 
> Then it works well for me (not everything tested, though).
> 
> > Unfortunately, MSys shell provides an environment which is somewhere
> > between Unix and Windows, and not entirely compatible with either. In
> > particular, any pathnames which GRASS sees will need to be compatible
> > with Windows, e.g. C:\path\to\file or C:/path/to/file rather than
> > MSys' /c/path/to/file convention.
> 
> Well, actually, as you can see above, for launching grass you need the 
> msys style.

Shell scripts need MSys-style paths. If you're lucky, the shell will
convert the paths to Windows format when running a Windows binary. 
Internally, WinGRASS requires valid Windows paths.

MSys usually handles this conversion for command-line arguments and
some environment variables, but not when writing data to files (e.g. 
you can end up with an MSys-style path for GISDBASE in $GISRC, and
then everything fails).

> > The focus of WinGRASS is to produce a *native* Windows version. Unless
> > you're building WinGRASS yourself, you shouldn't need MSys for
> > anything other than running shell scripts.
> 
> And even then, I guess other shells would also do the trick, such as 
> Gnuwin32's shell and tools such as awk and sed. Msys is more convenient 
> as the default installation contains these tools.

The issue is that all shells invariably include some form of Unix
emulation which has to be undone before the data can be passed on to
Windows functions. Sometimes the shell manages to do this
automatically, sometimes it doesn't. If it doesn't, you have to
perform the conversion yourself.

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