[GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules

[Glynn Clements]

M-Dàris Narti-B¹s wrote:-A

> as I'm not coder but simple user, I can not understand why letting program to 
> fail with user UNfrendly error is good point.

It would certainly be useful to improve error messages. Apart from
anything else, errors arising from executing commands from a menu item
shouldn't include the Tcl backtrace, only the actual error.

> If there could be discussion 
> about showing or hiding unavailable menu items*, then I don't see any reason 
> why there should be no check against does such module (file) exists.

As I said before, non-existence is only one possible problem. The
executable itself might exist, but it might require shared libraries
which are missing, or it may be a script which uses an executable
which doesn't exist.

> > Also, testing whether an executable is present isn't the same thing as
> > testing whether or not it can actually be run. It's arguably better to
> > treat all such problems in a similar manner (attempt to run the module
> > and show any specific errors to the user) than to treat specially the
> > case where the executable is absent.
> 
> Here are my first 3 lines in tcl/tk.
> W0ps - just found bug - it will fail IF $program already contains full path to 
> executable ($GISBASE/etc/gm/scripts/FOO).
> 
> --- gui/tcltk/gis.m/runandoutput.tcl.orig       2006-07-22 
> 12:29:48.000000000 +0300
> +++ gui/tcltk/gis.m/runandoutput.tcl    2006-08-03 23:09:43.000000000 +0300
> @@ -65,10 +65,15 @@
>  }
>  
>  proc run_ui {cmd} {
> -    global dlg path
> +    global dlg path env
>  
>      set program [lindex $cmd 0]
>  
> +    if { ![file executable $env(GISBASE)/bin/$program] }  {

Not everything is in $GISBASE/bin; some are in $GISBASE/scripts or
$GISBASE/etc/gm/script. Also, on Windows the file itself may have a
.exe suffix.

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