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 <glynn@gclements.plus.com>
