[GRASS-dev] GRASS & cygwin quite slow

[Glynn Clements]

Huidae Cho 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).
> 
> Windows path name conflicts with the ":" path separator used in many
> shell scripts.  Is the native Windows version of GRASS supposed to run only
> under MSys?  If so, we can add /c/msys/1.0 prefix to all path names
> stored in GISRC.

It would have to be c:/msys/1.0; the /c/<etc> syntax won't work with
MSVCRT functions (open() etc).

The main question is: in how many different places does this issue
arise? If it's just Init.sh, we can add a hack for MSys. If it's going
to keep cropping up, we need a more general solution.

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