Hamish <hamish_b@yahoo.com> writes:
[...]
> many other modules use grep, but g.mlist was/is the worst script for
> depending on module decorations. Others to consider are ones that
> parse 'd.mon -L', g.region without -g, and 'db.connect -p'. I haven't
> checked if any of those three use i18n macros. Of them db.connect
> shouldn't IMO. Anyway when we come across them the fix is easy to
> implement. (I don't like an "apply to all scripts" solution)
For every module formatting its output in a human-readable
manner by default there should probably be an option to format
it in a machine-readable one instead.
>>> The long term fix is to rewrite g.mlist not to be a hack.
>> It's rather `g.list' that should be extended to output in
>> machine-readable form. (I've already suggested the `-1' and
>> `--no-decoration' options to achieve that, though I haven't prepared
>> a patch as of yet.)
> right. I wonder how to deal with multiple mapsets? fully qualify
> name@mapset for all map names or use a #header line with the mapset
> name before each new mapset listing? Probably fully qualify
> everything: it's easy enough to strip off the mapset with 's/@.*$//'
> or `cut -f1 -d@` and much less weird to deal with.
I think it's a right solution.
> FWIW g.mlist just gives you all map names without qualification, but
> they will be in the mapset search path so it only becomes an issue if
> you have multiple maps of the same name in the mapset search path.
Would `g.list' be able to produce fully qualified names,
`g.mlist' could be made to either strip the mapset, or to pass
the names unaltered. It seems to be better not to alter the
names, unless an option is given.
It seems to me that the whole reason for producing a list of
non-qualified names in current `g.mlist' was that the qualified
list is much harder to produce. With `g.list' changed, it'd be
straightforward.
> (g.mremove explicitly limits itself to maps in the current mapset. It
> could use 'g.mlist mapset=.' instead of 'g.mlist mapset=`g.gisenv
> MAPSET`' but that's just cosmetic)
> I worry about using -1 and -l as they can be confused depending on
> the font;
However, this is consistent with the other utilities. Consider,
e. g., ls(1) or enscript(1).
> for many other modules we have used -g to tell the module to create
> parsable output. (why -g? I've no idea. but so it is)
I'd opt for the set of options, and not the single one, to
control the `g.list' output. In particular, I find one-column
decorated output useful.