[GRASS-dev] GRASS & cygwin quite slow

[Glynn Clements]

Glynn Clements wrote:

> > > Executing external programs (e.g. using g.list to generate a list of
> > > maps) doesn't work. The actual OpenGL rendering works fine.
> > 
> > This bombs in the prototype wxPython UI too. Is this somehow different from
> > other GRASS modules?
> 
> Oops. The NVIZ map browser uses "ls", not g.list.

But that's irrelevant; it was getting stuck on calling g.gisenv to get
GISDBASE etc. I've discovered that it seems to blocking on stdin;
pressing Return in the terminal allows it to continue, until the next
exec. Furthermore, running nviz as "nviz ... </dev/null" eliminates
the problem. However, putting a redirection in the exec command itself
doesn't help.

Another major problem with MSys is that it uses its own virtual
filesystem rooted at e.g. c:/msys/1.0. The shell takes care of
translating command-line arguments, but this causes problems with
scripts which write pathnames to files. E.g. etc/Init.sh sets GISDBASE
in $GISRC to an MSys pathname (e.g. /home/glynn/grass-data) while the
executables (being native Windows programs) need the real pathname
(e.g. c:/msys/1.0/home/glynn/grass-data).

I suspect that we'll need to replace Init.sh with a .bat/.cmd file for
Windows. Either that, or find a shell which doesn't mess around with
filenames.

I'm not sure how this will affect other shell scripts. MSys' bash can
recognise Windows pathnames, and doesn't attempt to translate them, so
using e.g. GISDBASE=`g.gisenv GISDBASE` shouldn't be a problem. I
don't know whether any other scripts write pathnames to files, though.

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