Markus Neteler wrote: > I sometimes need to rename mapsets and regularly run into the trap that > also the first row in the SEARCH_PATH files needs to be updated accordingly. > Since I tend to forget about this, maps in the current mapset are no longer > found and obscure errors pop up. > > Questions: > - why does the current mapset needs to be specified at all in SEARCH_PATH?
It doesn't "need" to be specified. You can have a search path which doesn't include the current mapset. However, this configuration will break many scripts, which tend to assume that a map created by a previous command will be accessible via its unqualified name. Note that similar problems can occur if other mapsets are ahead of the current mapset, as an unqualified name refers to the first map found in the search path, not necessarily the one in the current mapset. > - wouldn't it be better to auto-add the current mapset name internally? > - otherwise, could a test be added upon startup of GRASS to auto-add > the current mapset name is missing from SEARCH_PATH? Realistically, I think that the current mapset must always be at the head of the search path. Allowing it to be otherwise will be error-prone. Otherwise, we have to fix existing scripts to explicitly add the current mapset to any temporary map names. It's much simpler to change the library to match existing practice. Currently, g.mapsets adds the current mapset to the front of the search path if it isn't already present. In libgis, if SEARCH_PATH doesn't exist, a default path is created containing the current mapset followed by PERMANENT. If SEARCH_PATH does exist, it is used verbatim; the current mapset won't be searched if it isn't in SEARCH_PATH. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
