[GRASS-dev] new G_find_etc() and g.findetc

GRASS GIS GRASS GIS developer
1

Thanks to Glynn's expert help, I added a G_find_etc() function to libgis, and a companion g.findetc command.

These are used to locate support files for C and script modules that may be in a directory not inside the GRASS installation ($GISBASE/etc). They are intended for use by addon modules and scripts that are installed externally to the GRASS installation ($GISBASE). The search paths are specified in the env var GRASS_ADDON_ETC. If not found in those paths (or none are specified), it tries $GISBASE/etc.

To use, instead of hardwiring the etc path to $GISBASE:

   sprintf(path, "%s/etc/somefile", G_gisbase());

search for it with:

   path = G_find_etc("somefile");

and make sure to test for null = it wasn't found.

For scripts, use something like:

   fpath=`g.findetc file=somefile`

Works to find both files and folders, and subfolders. The Mac OS X app startup has been updated to add the default global and user addon etc folders to GRASS_ADDON_ETC.

This is a followup to my message from March:

http://grass.itc.it/pipermail/grass-dev/2007-March/029975.html

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy

2

William Kyngesburye wrote:

Thanks to Glynn's expert help, I added a G_find_etc() function to
libgis, and a companion g.findetc command.

was there ever any resolution to the question of if etc/ should be
renamed to something more appropriate, and more generally how to go
about cleaning up the mix of stuff in there? (separate platform specific
binary exe from static data files). Or are we happy with it as-is?

Something to consider before locking in the module name.

Hamish

3

On Apr 19, 2007, at 12:19 AM, Hamish wrote:

William Kyngesburye wrote:

Thanks to Glynn's expert help, I added a G_find_etc() function to
libgis, and a companion g.findetc command.

was there ever any resolution to the question of if etc/ should be
renamed to something more appropriate, and more generally how to go
about cleaning up the mix of stuff in there? (separate platform specific
binary exe from static data files). Or are we happy with it as-is?

Something to consider before locking in the module name.

...something I forgot to bring up...

Yeah, it's a bit of a klunky name. Even if etc/ stays as-is, I'm open to suggestions of a better name for it.

- find_file seems more appropriate, but that's taken to find mapset data files.

- find_data makes some sense (unix software often refers to shared resources such as etc/ and share/ as data), but it could easily be confused with finding mapset data files.

- find_resource? or find_rsrc? these are program resource data files we're looking for.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect