On Mon, May 2, 2011 at 7:05 PM, Glynn Clements <[email protected]> wrote: > > 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.
That's right (but rarely used). > 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. ... in fact, it will be mostly asking for troubles. >> - 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. Definitely - I'd vote for a library update. > Currently, g.mapsets adds the current mapset to the front of the > search path if it isn't already present. Yes, but this helps only if you call g.mapsets which is not necessarily the case. > 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. .. which was the trap I met too often in the past. Markus _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
