[GRASS-dev] GRASS & cygwin quite slow

[Huidae Cho]

On Tue, Aug 08, 2006 at 03:20:16AM +0100, Glynn Clements wrote:
> 
> 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).

You're right. I overlooked that only c:/ is working with MSVCRT.

> 
> 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.

Another problem is with the path separator.
PATH="c:/msys/1.0/.../grass/bin" does not work since it's translated to
PATH="c;c:\msys\1.0\msys\1.0\...\grass\bin".  MSVCRT functions use the
c:/msys/1.0 syntax, but once modules are compiled, they need
PATH=/c/msys/1.0 to find DLLs.

What I'm thinking is that everything can be done with the c:/msys/1.0
syntax including file I/O, but paths need to be converted to the
/c/msys/1.0 syntax whenever they are exported with putenv().

Huidae Cho

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