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

[Huidae Cho]

On Tue, Sep 19, 2006 at 06:53:33PM +0100, Glynn Clements wrote:
> 
> Huidae Cho wrote:
> 
> > > 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?
> 
> No, it's because you have a target named grass-xterm-wrapper, and a
> source file named grass-xterm-wrapper.c which is older than the
> target, so make assumes that it's supposed to compile and link
> grass-xterm-wrapper.c into grass-xterm-wrapper.
> 

Confirmed. You mean "*newer* than the target."

> > If the solution doesn't involve grass-xterm-wrapper, what could be
> > done for Windows *now*?
> 
> I'm not sure that anything *can* be done for Windows right now, other
> than "this feature doesn't work on Windows yet".
> 
> GRASS has two decades of history as a Unix package. Getting a native
> Windows version working isn't going to happen overnight. And trying to
> rush it will only make things harder in the long run.
> 
> > 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.
> 
> Running a command in a terminal and handling shell scripts are
> separate issues. Running a binary executable in a Windows console
> shouldn't involve sh.exe in any way.
> 
> More significantly, the problem of running scripts on Windows isn't
> limited to whether or not they are run in a terminal. Even
> non-interactive scripts need special treatment. On Unix, the first
> argument to execve() can be a binary executable or a script, and the
> kernel will handle the details. This doesn't work on Windows, which
> doesn't recognise the #! syntax.
> 
> Shell scripts need to be run via sh.exe (but *not* via "sh -c ..."). 
> But we don't really want to have to hardcode knowledge of whether a
> particular program is a binary or a script into gis.m.
> 
> Essentially, all calls to "exec" (or "open |...") in Tcl need to be
> modified to allow scripts to work under Windows. This requires a
> "launcher" which would determine whether the command is a binary or
> script based upon the first few bytes of the file (scripts begin with
> #! then the interpreter, Windows executables begin with "MZ"), and
> invoke the interpreter if necessary.

When sh.exe does that interpretation, why do we need another launcher?
Is it because of metacharacters?  What side effects can we expect if
sh.exe is used to run binary files?

> 
> You would need to map the path, as a "/bin/sh" probably won't be found
> at "C:\bin\sh.exe". One option is to look for an association for ".sh"
> in the registry (HKEY_CLASSES_ROOT\.<ext> for the type, then
> HKEY_CLASSES_ROOT\<type>\shell\open\command for the handler).
> 

Out of curiosity, is just adding ".sh" to the registry enough to run
*.sh through sh.exe?

Huidae

> Note that grass-xterm-wrapper *isn't* suitable as a launcher, as it is
> only used for commands which need to be run in a terminal.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>