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

[Michael Barton]

I suppose a partial solution would be to at least check to see if the
command file listed in the menu exists in one of the 3 standard locations
and return something on the order of "This GRASS command is not installed".
It wouldn't help if it was installed but not executable.

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: Fri, 4 Aug 2006 22:56:35 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: M?ris Nartišs <maris.gis at gmail.com>, <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
> nonexisting modules
> 
> 
> Michael Barton wrote:
> 
>> Glynn's right. I got ahead of myself in encouraging this fix. Making a
>> better error trapping is a good idea. However this script can't just look in
>> $GISBASE/bin, it also has to look in $GISBASE/scripts and $GISBASE/etc/gm(or
>> dm)/script.
> 
> And, as I already mentioned, a given command may or may not have a
> .exe suffix. E.g. in the MinGW versions which I've built, programs
> only get a .exe suffix if they don't contain any dots. OTOH, it's
> possible to build an executable with no dots and without a .exe
> suffix, and equally possible for an individual Makefile to force a
> .exe suffix on any executable.
> 
> More generally, trying to figure out in advance whether executing a
> given command will succeed is the wrong approach. The only reliable
> approach is to actually run the command and check whether or not it
> did succeed. If it didn't succeed, figuring out why isn't entirely
> straightforward, as the error message (corresponding to ENOENT) will
> vary between platforms, and depend upon the user's locale settings.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>