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

[Huidae Cho]

On Wed, Sep 20, 2006 at 01:00:00PM -0700, Michael Barton wrote:
> So far, I've been just a lurker on this discussion. It still seems that most
> of the fundamental changes to make compiling a Windows native GRASS will
> still be outside the GUI per se. But when this is worked out and if there
> still needs to be some changes in the TclTk code, let me know if I can help.

One change that I want to see is to define g_manual or something to
avoid running g.manual directly from within gis.m.  As mentioned before,
help_cmd invokes a user specified browser to show help pages.  Only
thing g.manual does in gis.m is simply helping a browser to display html
files, so there is no reason to use g.manual script when we have a
better alternative that works platform independently.  Current Help menu
(g.manual) doesn't work in Windows, but the GRASS help icon in each
module's dialog box works (help_cmd).

Thank you,
Huidae

> 
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics and Complexity
> Arizona State University
> 
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
> 
> 
> > From: Glynn Clements <glynn at gclements.plus.com>
> > Date: Wed, 20 Sep 2006 20:38:02 +0100
> > To: Huidae Cho <grass4u at gmail.com>
> > Cc: Michael Barton <michael.barton at asu.edu>, <grass-dev at grass.itc.it>
> > Subject: Re: [GRASS-dev] Re: MS-Windows native GRASS
> > 
> > 
> > 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."
> > 
> > Yes.
> > 
> >>>> 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?
> > 
> > Mostly, although there may be other issues. A shell is an extremely
> > heavy-weight solution.
> > 
> > Also, using sh.exe isn't exactly "native" Windows, IMHO. Obviously, if
> > we have shell scripts, then we need a shell to execute them. But we
> > shouldn't need it (and shouldn't be using it) for anything else.
> > 
> > It doesn't help that all of the shells which I've encountered perform
> > various Unix-compatibility tasks (e.g. translating filenames between a
> > virtual Unix filesystem and the native Windows filesystem). This
> > creates a risk of undesirable side-effects (e.g. filenames being
> > converted in some contexts but not in others, resulting in
> > mismatches).
> > 
> >>  What side effects can we expect if sh.exe is used to run binary
> >>  files?
> > 
> > There are two ways that the shell can be used. As an interpreter for
> > shell scripts, and as a mechanism for executing commands ("sh -c").
> > 
> > The latter is inappropriate on Windows, and not even a good idea on
> > Unix (where its normally used due to laziness). It's far more robust
> > to use the OS' mechanism(s) (execve(), spawnl()) directly.
> > 
> > Using the shell as an interpreter for shell scripts is safe, e.g.:
> > 
> > spawnl("sh.exe", "script", "arg1", "arg2", NULL);
> > 
> > However, this only works for shell scripts; if you pass the name of a
> > binary file in the above example, the shell will attempt to interpret
> > it as a shell script, which obviously won't work.
> > 
> > OTOH, using: 
> > 
> > spawnl("sh.exe", "-c", command, NULL);
> > 
> > requires that command be constructed from the name of a program and
> > its arguments, and that isn't as simple as concatenating the strings
> > with spaces in between. The simplest solution to the issue of
> > metacharacters is to replace any occurrences of the single quote
> > character in arguments with "'\''" (quote, backslash, quote, quote)
> > and surround each argument with single quotes.
> > 
> > Even then, there might be issues due to the shell messing with the
> > environment, signal handling, process groups etc (as well as possible
> > Unix-compatibility "features"). Shells are very complex programs.
> > 
> >>> 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?
> > 
> > I don't think you can map extensions directly to programs; normally,
> > the extension is mapped to a file type, then various actions are
> > associated with the type. E.g. ".vbs" is mapped to "VBSFile", then
> > actions are registered for "VBSFile".
> > 
> > OTOH; it's by no means guaranteed that the registered handler will do
> > the right thing. E.g. the "open" handler for .sh files might be a text
> > editor, or it might run them in a new console or an rxvt. In that
> > case, we might need a $GRASS_SH variable for Windows.
> > 
> > -- 
> > Glynn Clements <glynn at gclements.plus.com>
>