#1390: fully qualified name on g.mlist
-------------------------+--------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: LibGIS | Version: svn-trunk
Keywords: | Platform: All
Cpu: Unspecified |
-------------------------+--------------------------------------------------
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.
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.
New description:
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.
#1390: fully qualified name on g.mlist
-------------------------+--------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.mlist | Platform: All
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Old description:
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
}}}
New description:
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.
--
Comment(by martinl):
Replying to [ticket:1390 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
> }}}
#1390: fully qualified name on g.mlist
-------------------------+--------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.mlist | Platform: All
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by martinl):
Replying to [ticket:1390 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.
#1390: fully qualified name on g.mlist
-------------------------+--------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.mlist | Platform: All
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by martinl):
Replying to [comment:4 lucadelu]:
> Replying to [comment:3 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.
#1390: fully qualified name on g.mlist
-------------------------+--------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.mlist | Platform: All
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(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.
#1390: fully qualified name on g.mlist
-------------------------+--------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.mlist | Platform: All
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(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 safest^2 * user demand.
#1390: fully qualified name on g.mlist
-------------------------+--------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.mlist | Platform: All
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by glynn):
Replying to [comment:8 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).