[GRASS-dev] modules have problems with @mapset

[Glynn Clements]

Hamish wrote:

> > Yet again: an unqualified input map name does *not* refer to a map in
> > the current mapset. It refers to the first map with that name in the
> > search path. They aren't the same thing.
> 
> I was not aware that it was possible for the current mapset NOT to be
> the first entry in the search path?

>From a library perspective, the search path can be set to anything;
the current mapset doesn't even need to be in the path.

> If it is possible for that to
> happen, is there a valid reason why that should be allowed?

Suppose that you're generating a set of output maps from a set of
input maps, the two sets share a common naming policy, and the
operations aren't simple 1:1 operations (generating a single output
from a single input with the same name). It would be quite easy to
inadvertantly use a map from the output mapset instead of the input
mapset.

> The g.mapsets module insists on putting the current one first, I
> suppose it is possible to hack the $MAPSET/SEARCH_PATH file manaually
> to change the order, but I don't know why someone would want to.

AFAICT, g.mapsets adds the current mapset to the head of the search
path if it isn't already in the path, but won't move it if it's
elsewhere in the path.

> > Whether the GUI should add that for "new" maps is debatable.
> 
> Well as long as we stick to the "only write to the current mapset"
> rule^ it's redundant to qualify the name. And a lower signal to noise
> ratio means typos are harder to spot.
> (^ i.rectify)

The main problem there is that the parser interface doesn't have any
notion of "update in place", which is the situation for both
v.db.addtable and v.rast.stats.

The maps to be updated can't be declared as "new", because they have
to already exist. So, they're declared as "old", which means that the
GUI thinks that they can be in any mapset, and uses qualified names.

-- 
Glynn Clements <glynn at gclements.plus.com>