[GRASS-dev] Re: winGRASS

[Paul_Kelly]

Hello Michael
If you use the --with-opengl=aqua configure option then nviz will use the aqua Tcl/Tk, but I thought that was desired?
See William's comments here:
http://grass.itc.it/pipermail/grass-dev/2006-November/027480.html

Perhaps William just compiled his in the brief period while it was working, and now it is no longer working again?

Just an idea

Paul

On Tue, 6 Feb 2007, Michael Barton wrote:

I have a problem like this on versions of GRASS that I compile myself on my
Mac. It doesn't happen on versions that William Kyngesbury compiles. In my
case, all of GRASS is correctly compiling against an x11 tcltk that I
specify, but nviz insists on compiling against an aqua version also on my
machine. It creates a bad nviz binary file (the one that Bob's script
calls). I can substitute one that William compiles and all is well. Maybe
something similar is happening to you?

Michael

On 2/6/07 5:39 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Another outstanding issue is Nviz. It was working on Windows for a while
(looked great with Michael's new user interface improvements) but since
Bob changed it back to the script startup rather than running the nviz.exe
executable directly it no longer works on Windows. In fact I recently
tried to revert those changes and found it still wouldn't work; got stuck
at the Please Wait screen. A pity, because there is probably very little
needs changed to have it working again.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

[cmbarton]

Paul,

There are some aesthetic issues with aqua TclTk. It creates larger widgets
with extra space around them, for example. There are also a few
functionality issues, but not serious ones anymore (at least I don't think
so). Because most GRASS users are working in Linux, I try to use the x11
version for development to make sure it 'looks good' in that platform. I
should probably try the aqua version again to see how it is doing now.

William's compilations of nviz always seem to work currently and mine always
seem to fail.

I think that the nviz part of the compilation does respect the
--with-opengl=x11 or --with-opengl=aqua flag, but does not seem to respect
the --with-tcltk-includes=/usr/local/tcltk/include and
--with-tcltk-libs=/usr/local/tcltk/lib flags. It just goes to the system
default. I don't know enough about tweaking compilation parameters to know
how to fix this (In fact I don't hardly anything about tweaking compilation
parameters).

Michael

On 2/7/07 5:20 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Hello Michael
If you use the --with-opengl=aqua configure option then nviz will use the
aqua Tcl/Tk, but I thought that was desired?
See William's comments here:
http://grass.itc.it/pipermail/grass-dev/2006-November/027480.html

Perhaps William just compiled his in the brief period while it was
working, and now it is no longer working again?

Just an idea

Paul

On Tue, 6 Feb 2007, Michael Barton wrote:

I have a problem like this on versions of GRASS that I compile myself on my
Mac. It doesn't happen on versions that William Kyngesbury compiles. In my
case, all of GRASS is correctly compiling against an x11 tcltk that I
specify, but nviz insists on compiling against an aqua version also on my
machine. It creates a bad nviz binary file (the one that Bob's script
calls). I can substitute one that William compiles and all is well. Maybe
something similar is happening to you?

Michael

On 2/6/07 5:39 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Another outstanding issue is Nviz. It was working on Windows for a while
(looked great with Michael's new user interface improvements) but since
Bob changed it back to the script startup rather than running the nviz.exe
executable directly it no longer works on Windows. In fact I recently
tried to revert those changes and found it still wouldn't work; got stuck
at the Please Wait screen. A pity, because there is probably very little
needs changed to have it working again.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

[Markus_Neteler1]

Markus Neteler wrote on 02/07/2007 10:14 AM:

Paul, Moritz, all,

I have added the vector-DB problem to
http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status#What_is_missing.3F

My suggestion is to maintain the list there updated.

I have now also added Paul's comments on how to compile winGRASS
natively:
http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status
-> Compilation

Don't hesitate to update the page

Markus

[Glynn_Clements1]

Michael Barton wrote:

I think that the nviz part of the compilation does respect the
--with-opengl=x11 or --with-opengl=aqua flag, but does not seem to respect
the --with-tcltk-includes=/usr/local/tcltk/include and
--with-tcltk-libs=/usr/local/tcltk/lib flags. It just goes to the system
default. I don't know enough about tweaking compilation parameters to know
how to fix this (In fact I don't hardly anything about tweaking compilation
parameters).

The NVIZ Makefile will add both sets of -I switches to the compilation
command. Those switches will affect how all headers are located. You
can't tell the compiler to look for specific headers in specific
directories.

I note that the NVIZ Makefile *doesn't* use $(OPENGLINC), which is
almost certainly a bug.

This doesn't affect the version of Tcl/Tk used for d.m/gis.m, which is
determined at run-time by $GRASS_WISH.

--
Glynn Clements <glynn@gclements.plus.com>

[mlennert]

On Wed, February 7, 2007 01:39, Paul Kelly wrote:

On Mon, 18 Dec 2006, Moritz Lennert wrote:

- I had hoped that Radim's patch for dbmi_client
(http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might
solve the issue I've had with the db protocol errors, but apparently
this
is not the case. When I push the 'show the attribute columns' in a
vector
panel, I still get

*******
Displaying column types/names for database connection of layer 1:
dbmi: Protocol error

Cannot open table <streams>
********

and a 'v.db.select' on the same map gives me:

********
'vector/streams' was found in more mapsets (also found in user1).
dbmi: Protocol error

Cannot open select cursor
*********

Radim, as you have been working on this these days, do you have an idea
what might be wrong ?

I can confirm similar problems. I tried to import a Shapefile with
v.in.ogr. I went quite deep into debugging it and got nowhere at all,
although I should have taken better notes. I did confirm though that
compiling the library with -mwindows as Radim suggested on the list made
no difference either. I think trying with a different database, PostgreSQL
perhaps is the next big step to debugging this. See if the behaviour is
the same as with dbf and if not we can isolate it a bit more.
(Markus, this is what you were asking about what would be the next step
towards solving this.)

Ok, so at least for me this will be one of the current priorities in
trying to debug.

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

No, I still see exactly the same situation (with cvs from Feb. 5): greyed
out in individual module gui, error message in gis.m layer panel.

- export map canvas to graphics file:

couldn't execute "rm": no such file or directory
couldn't execute "rm": no such file or directory
   while executing
"exec rm $path.ppm"
   ("jpg" arm line 7)
   invoked from within
"switch $type {
                      "ppm" {
                              return
                      }
                      "tif" {
                              exec gdal_translate $path.ppm $path.tif
-of GTI$
                              exec rm $path.ppm
                      }
                      "bmp" {
                              e..."
   (procedure "MapToolBar::savefile" line 22)
   invoked from within
"MapToolBar::savefile jpg 50"
   (menu invoke)

So, graphics file gets created, but the original ppm file is not erased.

I think Michael has fixed those occurences of exec rm now so the Tcl file
delete function is used. So it should be OK.

Yes, works now.

- New thing in current (5/2) version: it seems that the grass63.bat file
is not adapted and copied to the bin directory during 'make install'.

Next to the db issues, I propose to actually work through the GDF tutorial
to test the functionalities in there. Should be a good starting point.

Moritz

[Paul_Kelly]

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

No, I still see exactly the same situation (with cvs from Feb. 5): greyed
out in individual module gui, error message in gis.m layer panel.

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. Does g.manual work for you when you run it from the command-line (grass63.bat -text)?

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.
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?). The $pgm_name there, wherever it is derived from, doesn't have .exe at the end.

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?

[...]

- New thing in current (5/2) version: it seems that the grass63.bat file
is not adapted and copied to the bin directory during 'make install'.

This should be fixed as of yesterday, also the problem with the directory separator characters in grass63.bat should be all sorted.

Paul

[mlennert]

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

[cmbarton]

As best I can tell, g.manual [module name] simply calls whatever browser has
been set in the environmental variable GRASS_HTML_BROWSER. It seems like a C
shortcut to using TclTk code to do the same thing.

$pgm_name is simply a variable to store the name of the current module
(d.rast, d.vect, etc.)

The TclTk code below executes whatever is stored in GRASS_HTML_BROWSER to
open the doc file stored at [module name].html.

g.manual shouldn't need a bash environment any more than any other GRASS
command.

If there are problems with the help buttons on the GUI options panels and
not on the module dialogs, I think more likely, it is a problem with the
"run" procedure used in the options panels to launch g.manual. Look at
raster.tcl and change how it starts in a couple ways. Try "spawn" instead of
"run". Also try the solution I mentioned with the execute procedure and the
devnull variable.

Michael

On 2/12/07 5:14 PM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

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

__________________________________________
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

[Glynn_Clements1]

Moritz Lennert wrote:

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

That's due to this line in lib/init/init.bat:

if "%GRASS_HTML_BROWSER%"=="" set GRASS_HTML_BROWSER=%SYSTEMDRIVE%/PROGRA~1/INTERN~1/IEXPLORE.EXE

It should probably be:

if "%GRASS_HTML_BROWSER%"=="" set GRASS_HTML_BROWSER=%ProgramFiles%/INTERN~1/IEXPLORE.EXE

%ProgramFiles% will be set to the system's "Program Files" directory
(or whatever it is called on a particular system, e.g. "C:\Programme"
on a German system).

However, there are better solutions available on Windows, e.g.

  rundll32 url.dll,FileProtocolHandler <filename or URL>

E.g.:

  rundll32 url.dll,FileProtocolHandler "c:\Cygwin\usr\local\grass-6.2.1\docs\html\grass6.html"
or:
  rundll32 url.dll,FileProtocolHandler "http://grass.itc.it"

This has the advantage of using the default application rather than
hardcoding MSIE.

--
Glynn Clements <glynn@gclements.plus.com>

[mlennert]

On 13/02/07 13:16, Glynn Clements wrote:

Moritz Lennert wrote:

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

That's due to this line in lib/init/init.bat:

if "%GRASS_HTML_BROWSER%"=="" set GRASS_HTML_BROWSER=%SYSTEMDRIVE%/PROGRA~1/INTERN~1/IEXPLORE.EXE

It should probably be:

if "%GRASS_HTML_BROWSER%"=="" set GRASS_HTML_BROWSER=%ProgramFiles%/INTERN~1/IEXPLORE.EXE

%ProgramFiles% will be set to the system's "Program Files" directory
(or whatever it is called on a particular system, e.g. "C:\Programme"
on a German system).

However, there are better solutions available on Windows, e.g.

  rundll32 url.dll,FileProtocolHandler <filename or URL>

E.g.:

  rundll32 url.dll,FileProtocolHandler "c:\Cygwin\usr\local\grass-6.2.1\docs\html\grass6.html"
or:
  rundll32 url.dll,FileProtocolHandler "http://grass.itc.it"

This has the advantage of using the default application rather than
hardcoding MSIE.

Actually IIUC, it's not only MSIE which is hardcoded, but also the fact that "Program Files" and "Internet Explorer" are the (alphabetically first directories) with their respective abbreviation, i.e. if someone has something like c:\Programe Files\Internet Ace, this would be Intern~1 and Internet Explorer would become Intern~2. Do I understand this correctly ?

Would your solution translate to:

if "%GRASS_HTML_BROWSER%"=="" set GRASS_HTML_BROWSER="rundll32 url.dll,FileProtocolHandler"

or does this have to be handled outside the GRASS_HTML_BROWSER variable ?

Moritz

[Glynn_Clements1]

Moritz Lennert wrote:

>> 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".
>
> That's due to this line in lib/init/init.bat:
>
> if "%GRASS_HTML_BROWSER%"=="" set GRASS_HTML_BROWSER=%SYSTEMDRIVE%/PROGRA~1/INTERN~1/IEXPLORE.EXE
>
> It should probably be:
>
> if "%GRASS_HTML_BROWSER%"=="" set GRASS_HTML_BROWSER=%ProgramFiles%/INTERN~1/IEXPLORE.EXE
>
> %ProgramFiles% will be set to the system's "Program Files" directory
> (or whatever it is called on a particular system, e.g. "C:\Programme"
> on a German system).
>
> However, there are better solutions available on Windows, e.g.
>
> rundll32 url.dll,FileProtocolHandler <filename or URL>
>
> E.g.:
>
> rundll32 url.dll,FileProtocolHandler "c:\Cygwin\usr\local\grass-6.2.1\docs\html\grass6.html"
> or:
> rundll32 url.dll,FileProtocolHandler "http://grass.itc.it"
>
> This has the advantage of using the default application rather than
> hardcoding MSIE.

Actually IIUC, it's not only MSIE which is hardcoded, but also the fact
that "Program Files" and "Internet Explorer" are the (alphabetically
first directories) with their respective abbreviation, i.e. if someone
has something like c:\Programe Files\Internet Ace, this would be
Intern~1 and Internet Explorer would become Intern~2. Do I understand
this correctly ?

The ~ suffixes are allocated in order of creation, so that they don't
change as new entries are added to or removed from the directory.

Even so, I don't see any reason to abbreviate the directory names.

Would your solution translate to:

if "%GRASS_HTML_BROWSER%"=="" set GRASS_HTML_BROWSER="rundll32
url.dll,FileProtocolHandler"

or does this have to be handled outside the GRASS_HTML_BROWSER variable ?

I'd try setting GRASS_HTML_BROWSER as above; if that doesn't work, you
might need to create a batch file to do the same thing.

--
Glynn Clements <glynn@gclements.plus.com>

[mlennert]

On Tue, February 13, 2007 17:06, Glynn Clements wrote:

Moritz Lennert wrote:

Would your solution translate to:
if "%GRASS_HTML_BROWSER%"=="" set GRASS_HTML_BROWSER="rundll32
url.dll,FileProtocolHandler"
or does this have to be handled outside the GRASS_HTML_BROWSER variable ?

I'd try setting GRASS_HTML_BROWSER as above; if that doesn't work, you

might need to create a batch file to do the same thing.

Maybe I simply did not quote the rundll32 line correctly, but I did not
manage to make it work. However, it works great using a
bin/url_handler.bat which simply contains:

rundll32.exe url.dll,FileProtocolHandler %*

(any quoting needed here ?)

and then set GRASS_HTML_BROWSER in Init.bat to url_handler.bat.

Now I get my default browser when clicking on the help button in the
startup screen or in a standalone module gui called from the command line.

However, this does not solve the g.manual issue. I still get
"LOCATION_NAME not set" whenever I try to launch g.manual. Actually I get
this whenever I try to launch something (script or C-binary) via
%GRASS_SH% which is set to msys' sh.exe. But even within this shell, echo
$LOCATION_NAME gives me the correct location name, so I don't understand
where this message comes from

I can reproduce this also in the GIS Manager: whenever I select a module
in the menu which is actually a script, I get the "LOCATION_NAME not set"
error.

I can get g.manual to run (i.e. show it's gui window), by changing
bin/g.manual.bat from

@"%GRASS_SH%" -c '"%GISBASE%/scripts/g.manual" %*'

to

g.parser "%GISBASE%/scripts/g.manual" %*

But then, when I enter a module name and press Run, I get:

GRASS 6.3.cvs (spearfish60):C:\ >g.parser
"c:/GRASS/grass-6.3.cvs/scripts/g.manual" entry=d.vect
Starting browser <url_handler.bat> for module d.vect...

But nothing happens. Same on the command line, where I also only get the
message "Starting browser <url_handler.bat> for module d.vect..." but
nothing happens.

When I try to apply the same recipe to v.dissolve it continues to fail
with "LOCATION_NAME not set" until I comment out the call to v.extract...

I have the feeling that the g.parser route is the wrong one, but I was
hpoing it might give us an idea of where this error comes from. Am tired
and a bit lost, so I think I'll better get some sleep and think about it
more tomorrow.

Moritz

[Glynn_Clements1]

Moritz Lennert wrote:

>> Would your solution translate to:
>> if "%GRASS_HTML_BROWSER%"=="" set GRASS_HTML_BROWSER="rundll32
>> url.dll,FileProtocolHandler"
>> or does this have to be handled outside the GRASS_HTML_BROWSER variable ?
>
> I'd try setting GRASS_HTML_BROWSER as above; if that doesn't work, you
might need to create a batch file to do the same thing.

Maybe I simply did not quote the rundll32 line correctly, but I did not
manage to make it work. However, it works great using a
bin/url_handler.bat which simply contains:

rundll32.exe url.dll,FileProtocolHandler %*

(any quoting needed here ?)

It probably wouldn't hurt to put quotes around %*.

If it doesn't work without a batch file, that suggests that
$GRASS_HTML_BROWSER is interpreted as a command name, rather than a
command and arguments (i.e. it's being used as the first argument to
exec, rather than being parsed into a list to which the filename is
appended).

That's probably the right thing to do; if it was beig parsed into a
list, you wouldn't be able to specify a path which contained spaces.

However, this does not solve the g.manual issue. I still get
"LOCATION_NAME not set" whenever I try to launch g.manual. Actually I get
this whenever I try to launch something (script or C-binary) via
%GRASS_SH% which is set to msys' sh.exe. But even within this shell, echo
$LOCATION_NAME gives me the correct location name, so I don't understand
where this message comes from

LOCATION_NAME is a GRASS variable, not an environment variable. Check
that the value of $GISRC and the contents of the file to which it
refers are sane.

--
Glynn Clements <glynn@gclements.plus.com>

[mlennert]

On Wed, February 14, 2007 02:03, Glynn Clements wrote:

Moritz Lennert wrote:

However, this does not solve the g.manual issue. I still get
"LOCATION_NAME not set" whenever I try to launch g.manual. Actually I
get
this whenever I try to launch something (script or C-binary) via
%GRASS_SH% which is set to msys' sh.exe. But even within this shell,
echo
$LOCATION_NAME gives me the correct location name, so I don't understand
where this message comes from

LOCATION_NAME is a GRASS variable, not an environment variable. Check
that the value of $GISRC and the contents of the file to which it
refers are sane.

That was it: echo %GISRC% gives .grassrc6, but it needs c:/.grassrc6 to work.
(As mentioned in a previous mail I had tried with g.gisenv before and it
showed a correct LOCATION_NAME, but I think I got confused between two
installations of GRASS - now it also fails with "LOCATION not set" until I
correct the $GISRC setting ...).

Now g.manual starts in its original form (no playing around with g.parser
calls), but I get:

g.manual entry=d.vect
Starting browser <url_handler.bat> for module d.vect...
url_handler.bat file://c:/GRASS/grass-6.3.cvs/docs/html/d.vect.html

And then nothing happens.

Moritz

[Glynn_Clements1]

Moritz Lennert wrote:

Now g.manual starts in its original form (no playing around with g.parser
calls), but I get:

g.manual entry=d.vect
Starting browser <url_handler.bat> for module d.vect...
url_handler.bat file://c:/GRASS/grass-6.3.cvs/docs/html/d.vect.html

And then nothing happens.

Does running the command directly from a command prompt work? It's
possible that the MSys shell is interfering in some way.

--
Glynn Clements <glynn@gclements.plus.com>

[mlennert]

On 14/02/07 11:57, Glynn Clements wrote:

Moritz Lennert wrote:

Now g.manual starts in its original form (no playing around with g.parser
calls), but I get:

g.manual entry=d.vect
Starting browser <url_handler.bat> for module d.vect...
url_handler.bat file://c:/GRASS/grass-6.3.cvs/docs/html/d.vect.html

And then nothing happens.

Does running the command directly from a command prompt work? It's
possible that the MSys shell is interfering in some way.

Yes, running
url_handler.bat file://c:/GRASS/grass-6.3.cvs/docs/html/d.vect.html
launches my default browser with the d.vect man page.

Concerning the wrong setting for GISRC, this seems to come from the following line in etc/Init.bat:

set WINGISRC=%HOME%\.grassrc6

'echo %HOME%' just results in %HOME%. Is HOME a valid Win env variable (and what would $HOME actually be in a windows environment) ?

Moritz

[Glynn_Clements1]

Moritz Lennert wrote:

Concerning the wrong setting for GISRC, this seems to come from the
following line in etc/Init.bat:

set WINGISRC=%HOME%\.grassrc6

'echo %HOME%' just results in %HOME%. Is HOME a valid Win env variable

No, in the sense that Windows doesn't set it by default. HOME should
probably be set to %USERPROFILE% if it isn't already set.

(and what would $HOME actually be in a windows environment) ?

%USERPROFILE% will typically be C:\Documents and Settings\<username>

(subject to localisation of directory names).

--
Glynn Clements <glynn@gclements.plus.com>

[mlennert]

On Wed, February 14, 2007 20:20, Glynn Clements wrote:

Moritz Lennert wrote:

Concerning the wrong setting for GISRC, this seems to come from the
following line in etc/Init.bat:

set WINGISRC=%HOME%\.grassrc6

'echo %HOME%' just results in %HOME%. Is HOME a valid Win env variable

No, in the sense that Windows doesn't set it by default. HOME should
probably be set to %USERPROFILE% if it isn't already set.

Yes, this works.

Paul, do you want me to integrate such things directly in CVS, or do you
prefer doing it yourself ?

Moritz

[mlennert]

On Wed, February 14, 2007 14:23, Moritz Lennert wrote:

On 14/02/07 11:57, Glynn Clements wrote:

Moritz Lennert wrote:

Now g.manual starts in its original form (no playing around with
g.parser
calls), but I get:

g.manual entry=d.vect
Starting browser <url_handler.bat> for module d.vect...
url_handler.bat file://c:/GRASS/grass-6.3.cvs/docs/html/d.vect.html

And then nothing happens.

Does running the command directly from a command prompt work? It's
possible that the MSys shell is interfering in some way.

Yes, running
url_handler.bat file://c:/GRASS/grass-6.3.cvs/docs/html/d.vect.html
launches my default browser with the d.vect man page.

Still trying to solve this issue. The path of the g.manual command is
currently:

bin/g.manual.bat launches GRASS_SH to call scripts/g.manual:
@"%GRASS_SH%" -c '"%GISBASE%/scripts/g.manual" %*'

scripts/g.manual is a normal shell script which calls:

"$GRASS_HTML_BROWSER" file://"$GRASS_DOC_BASE"/docs/html/$1.html

If $GRASS_HTML_BROWSER is set to the path to firefox of IE they run
perfectly. If it is set to url_handler.bat, I get the above message
without anything happening.

url_handler.bat contains just one line:

rundll32.exe url.dll,FileProtocolHandler "%*"

Any hints ?

We obviously could just tell people that they have to set
GRASS_HTML_BROWSER in Init.bat to their favorite browser...

Moritz

[Paul_Kelly]

On Tue, 20 Feb 2007, Moritz Lennert wrote:

On Wed, February 14, 2007 20:20, Glynn Clements wrote:

Moritz Lennert wrote:

Concerning the wrong setting for GISRC, this seems to come from the
following line in etc/Init.bat:

set WINGISRC=%HOME%\.grassrc6

'echo %HOME%' just results in %HOME%. Is HOME a valid Win env variable

No, in the sense that Windows doesn't set it by default. HOME should
probably be set to %USERPROFILE% if it isn't already set.

Yes, this works.

Paul, do you want me to integrate such things directly in CVS, or do you
prefer doing it yourself ?

Yes, please go ahead if you think it is an improvement. That issue specifically (setting the HTML viewer for help) I wasn't very happy with the way I'd temporarily set it anyway. Another idea I had was that we could have an alternative Windows batch file version of g.manual. It's an important module in its own way - don't want users to have to install a bash shell interpreter just to launch their web browser. There could even be a general mechanism for scripts that if there is a .bat version that is installed, otherwise the wrapper to call the shell interpreter is installed.

Paul