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

[Glynn Clements]

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.

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

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

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>