[GRASS-dev] Message standardization

Glynn Clements glynn at gclements.plus.com
Mon Dec 17 12:54:00 EST 2007

Moritz Lennert wrote:

> > <aside> the GRASS 6.3 tcl GUI always appends the @mapset to the map 
> > name, even for the current mapset. Personally I don't like that- I 
> > think it's ugly noise. It does that to clarify to the user which map 
> > will be used from the g.mapsets search path if the map name exists in
> >  multiple mapsets.
> IIRC, the reason for putting the @mapset was not really to clarify
> anything to the user, but rather to avoid the message:
> WARNING: 'vector/fields' was found in more mapsets (also found in
>           PERMANENT).
> WARNING: using 'fields at user1'.

There's another reason: an unqualified map name does not necessarily
refer to the map with that name in the current mapset, but to the
first map with that name in the mapset search path. The current mapset
comes first in the search path *by default*, but that can be changed.

Unqualified map names are a convenience for command-line use. There is
no need to use them when the user is selecting a specific map from a
map browser.

> > FWIW I think that using @mapset should be limited to cases where 
> > mapset is not the current mapset. And should *always* be used in that
> >  case whether the input came from the user or not.
> This would imply that:
> On 16/12/07 03:18, Hamish wrote:
> > I would be happy to just document/recode so that the current mapset
> > is always searched first, PERMANENT second, and all others after
> > (alpha? filesystem order?). </aside>

So long as we have a mapset search path, it makes sense to allow the
user to set it to whatever they want.

> It would be interesting to see how many people deliberately set their 
> mapset search path to something different than the default. This would 
> then give us a notion of how much nuisance such a change would create ?

It doesn't matter how common this is, only that it's possible.

Glynn Clements <glynn at gclements.plus.com>

More information about the grass-dev mailing list