[GRASS-dev] Re: winGRASS

[Moritz Lennert]

On Fri, February 9, 2007 15:25, Paul Kelly wrote:
> On Fri, 9 Feb 2007, Moritz Lennert wrote:
>
>>>> - Help does not work. In individual command windows, the help button
>>>> is
>>>> desactivated. In layer panels in the main GIS Manager window, when I
>>>> push
>>>> the help button, I get:
>>>>
>>>> child process exited abnormally
>>>> child process exited abnormally
>>>>    while executing
>>>> "exec -- g.manual d.vect >& NUL:"
>>>>    ("eval" body line 1)
>>>>    invoked from within
>>>> "eval [list exec -- $cmd] $args >& $devnull"
>>>>    (procedure "run" line 8)
>>>>    invoked from within
>>>> "run g.manual d.vect"
>>>>    ("uplevel" body line 1)
>>>>    invoked from within
>>>> "uplevel \#0 $cmd"
>>>>    (procedure "Button::_release" line 18)
>>>>    invoked from within
>>>> "Button::_release .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.name.e"
>>>>    (command bound to event)
>>>>
>>>
>>> This was due to g.parser assuming the shell (c:\msys\1.0\bin\sh.exe)
>>> that
>>> it needed to run g.manual (required for all the help) was in the path.
>>> I
>>> have since changed the way it operates on Windows to first check the
>>> environment variable GRASS_SH before looking for sh.exe in the path. So
>>> the help should work now.

Because of problems in the localisation of m4sugar of bison, I had moved
everything up from c:\msys\1.0 to c:\msys, so it couldn't find sh.exe...

Another similar problem: I have a German language WinXP installed on my
machine in which programs are installed at c:\Programme and not
"c:\Program Files".


> OK this seems very complicated. For me, it works from the button with the
> GRASS logo superimposed with a green question mark in the layer panel. It
> also works from the Help menu in gis.m.

Both still don't work for me, but I have been having trouble with the
setting of the variables GRASS_SH and GRASS_HTML_BROWSER (and it's getting
late and I don't have the energy to continue trying)

> Does g.manual work for you when
> you run it from the command-line (grass63.bat -text)?

No, when I launch g.manual from the command line I get:

ERROR: LOCATION_NAME is not set

but both g.gisenv and 'echo %LOCATION_NAME%' give me the correct content
for this variable...

>
> The problem with the greyed out button is due to this check in the
> make_fun_buttons() function in gui/tcltk/gis.m/runandoutput.tcl
>
>   # Turn off help button if the help file doesn't exist
>   if {! [file exists $env(GISBASE)/docs/html/$pgm_name.html]} {
>           $buttonframe.help configure -state disabled
>   }
>
> For some reason $pgm_name has .exe at the end so the test fails.

Just to add: in docs/html there are a few manuals which have *.exe.html: 
modcolr.exe.html  modhist.exe.html     v.voronoi.exe.html
modcats.exe.html  modhead.exe.html  v.delaunay.exe.html

Don't know why those do...



> BUT - this is just a clone of the code for the standalone Tcl/Tk dialog in
> lib/gis/gui.tcl, and it works there (for me anyway - can you confirm if
> you run a command from the command-line without any arguments that the
> Help button isn't greyed out and works?)

After correcting for the above problems with hard-coded paths, this works.


>. The $pgm_name there, wherever it
> is derived from, doesn't have .exe at the end.

The titles of the module windows also do not show the .exe suffix,
contrary to the windows opened by gis.m.

>
> I'm really not sure where it's coming from; find Tcl code hard enough to
> follow anyway and not sure about the way everything interacts here anyway.
>
> Another interesting point is that in lib/gis/gui.tcl the help button runs:
> exec $env(GRASS_HTML_BROWSER) $env(GISBASE)/docs/html/$pgm_name.html &
> whereas most places in gis.m run g.manual $pgm_name or something similar.
> As g.manual requires a bash interpreter to run, maybe the former solution
> is more platform-independent? Or are other places not supposed to access
> $GRASS_HTML_BROWSER - should it be just for g.manual to use?
>

Maybe Michael or Glynn can help us with this ?

Moritz