[GRASS-dev] Re: MS-Windows native GRASS

[Huidae Cho]

On Tue, Sep 19, 2006 at 11:38:20AM +0100, Glynn Clements wrote:
> 
> Huidae Cho wrote:
> 
> > > That's a mistake. As the name implies, grass-xterm-wrapper is supposed
> > > to be a front-end to an xterm-like terminal program. Its sole purpose
> > > is to allow terminals other than xterm to be used for programs which
> > > require a terminal. Once we eventually eliminate the need to use a
> > > terminal, it will go away altogether.
> > 
> > I agree, rxvt may be more suitable for the wrapper. But, curses based
> > modules (I didn't count how many modules actually depend on this library)
> > don't work with rxvt and that's why I chose cmd.exe for winGRASS.  For
> > example, grass -text doesn't work in rxvt.
> 
> cmd.exe isn't a terminal emulator, it's a shell. Windows automatically
> creates consoles for console-mode programs such as cmd.exe (unless you
> use "start /b ...").
> 
> While *something* needs to be done on Windows, the solution *doesn't*
> involve grass-xterm-wrapper. Which is why I've reverted the recent
> attempt to replace grass-xterm-wrapper (it was getting compiled on
> Linux, where it totally won't work; there is no sh.exe on Linux).

Probably, that is because of cross-compiling or wrong definition of
MINGW in include/Make/Platform.make?  If the solution doesn't involve
grass-xterm-wrapper, what could be done for Windows *now*?  If there are
no alternative ways of getting terminals working on Windows, I think
it's better to keep it until someone comes up with a better idea
although you may not like it.

As you mentioned above, no modules should require any user interaction
if they're called from within GUI.  Otherwise, there would be no way to
make a platform independent GUI.

> 
> Note that it wouldn't have worked on Windows either, as it made no
> attempt at escaping shell metacharacters.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>