Opened 8 years ago

Closed 3 years ago

#1390 closed enhancement (worksforme)

fully qualified name on g.mlist

Reported by: lucadelu Owned by: grass-dev@…
Priority: normal Milestone: 7.0.5
Component: Default Version: svn-trunk
Keywords: g.mlist Cc:
CPU: Unspecified Platform: All

Description (last modified by martinl)

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.

Change History (12)

comment:1 Changed 8 years ago by martinl

Component: LibGISDefault
Description: modified (diff)
Keywords: g.mlist added
Type: defectenhancement

comment:2 in reply to:  description Changed 8 years ago by martinl

Description: modified (diff)

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

comment:3 in reply to:  description ; Changed 8 years ago by 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

comment:4 in reply to:  3 ; Changed 8 years ago by lucadelu

Replying to martinl:

g.mlist -m

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

comment:5 in reply to:  4 Changed 8 years ago by 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.

comment:6 Changed 7 years ago by martinl

Any opinions from power users?

comment:7 Changed 7 years ago by 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

comment:8 Changed 7 years ago by 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 safest2 * user demand.

Hamish

comment:9 in reply to:  8 Changed 7 years ago by 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).

comment:10 Changed 5 years ago by 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

comment:11 Changed 3 years ago by martinl

Milestone: 7.0.07.0.5

comment:12 Changed 3 years ago by martinl

Resolution: worksforme
Status: newclosed

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

Note: See TracTickets for help on using tickets.