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

[Māris Nartišs]

Hi,

as I'm not coder but simple user, I can not understand why letting program to 
fail with user UNfrendly error is good point. 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.

And second - I never understood how RT works (yea, it's definitely not 
Bugzilla), so You probably missed my proposed 3line quickfix. So - please 
take a look at it and say a word - does such user friendly error handling is 
bad for GRASS?

Just my 3c to make GRASS better,
Maris.

On Friday 04 August 2006 01:19, Glynn Clements wrote:
> 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] }  {
+      tk_messageBox -icon error -message [G_msg "Sorry, your GRASS 
installation lacks module \"$program\""]
+      return
+    }
+
     set code [exec -- $program --tcltk]
 
     set path .dialog$dlg