fully qualified name on g.mlist

[lucadelu]

I think that should be better to have the fully qualified name on g.mlist command because the output now it is unclear. The user can't understand in which mapset are the maps.

[martinl]

Replying to lucadelu:

I think that should be better to have the fully qualified name on g.mlist command because the output now it is unclear. The user can't understand in which mapset are the maps.

g.mlist -m

[martinl]

Replying to lucadelu:

I think that should be better to have the fully qualified name on g.mlist command because the output now it is unclear. The user can't understand in which mapset are the maps.

g.mlist -m

[lucadelu]

Replying to martinl:

g.mlist -m

sorry, I didn't see it. Maybe the -m flag could be set by default?

[martinl]

Replying to lucadelu:

Replying to martinl:

g.mlist -m

sorry, I didn't see it. Maybe the -m flag could be set by default?

Only one solution is to modify behaviour of g.mlist to print fully qualified names by default and change -m flag to not print mapset names. I am not sure if this change is necessary.

[martinl]

Any opinions from power users?

[hamish]

my 2c: leave it off by default and better adverstize/use the -m flag to fully qualify them if it is needed by some auto-script.

I use common map names between diff't mapsets and have never had the need for such a thing personally, but who knows what other power scripters do. I always use mapset=. for cases where I need to be sure that I'm pulling from just the current MAPSET. You are protected from large chaos by the only-allowed to write (ie remove or overwrite) local maps restriction.

there are valid arguments on both sides, but to me the added clutter makes subtle errors harder to spot by eye, which is in my personal opinion more critical than seeing the louder 'this map is available in multiple mapsets' warning.

Hamish

[hamish]

again, there are valid arguments on both sides, but one technical reason not to use -m by default: it chews up CLI space if you use it like g.module input=`g.mlist rast sep=,` , since often you have lots of maps but just 4096 chars to describe them in. And when you overflow that the error can do odd things (e.g. if the buffer ends right at the end of a map name [~10% chance] and it then silently gives you a r.series result for the first ~275 days of data instead of 365).

I'm sure others can think of pulling from the wrong mapset scenarios, I guess it's a case of which alternative fails the safest^{2 * user demand.}

Hamish

[glynn]

Replying to hamish:

often you have lots of maps but just 4096 chars to describe them in.

The 4k limit is ancient history on Linux (prior to 2.6.23 it was 128k, now it's 1/4 of RLIMIT_STACK). Other platforms may still have small limits.

I'm sure others can think of pulling from the wrong mapset scenarios,

Indeed.

r55041 + r55042 automatically uses a qualified name where the unqualified name refers to the wrong map.

It's possible that we might need an option to suppress this behaviour (e.g. for scripts which aren't expecting to see an @ and for some reason don't need to care about the ambiguity).

[neteler]

Current state (r62667): g.mlist and old g.list have been merged into a new single g.list:

GRASS 7.0.0svn (nc_spm_08_grass7):~ > g.list rast | grep lsat7 | grep _10
lsat7_2002_10
lsat7_2000_10


GRASS 7.0.0svn (nc_spm_08_grass7):~ > g.list -m rast | grep lsat7 | grep _10
lsat7_2002_10@PERMANENT
lsat7_2000_10@landsat

[martinl]

No activity last 22 months, closing, feel free to reopen if needed.