[GRASS-dev] Re: [GRASS-SVN] r49205 - in grass/trunk: lib/python raster/r.info

[Hamish]

hamish:
> > undo r49166: units, vdatum, and title can not be
> > eval'd so needed to be split out. on doing that it was
> > apparent that -g needs to act the same as g.region and
> > v.info modules -- basic region info only. -s is debatable to
> > belong to -g or not, but -gs is very easy if needed.

Martin  wrote:
> I highly *disagree* with this revert!
> Merging very specific options which just prints one information
> to generic `-g` is a good idea (from my POV).

-g as a shell style debug dump of all internal variables does
not provide a clean interface for command line users to work with.

'r.info -r mapname' is a beautiful thing when working from the
command line. really, it is. simple, to the point, just what
you want.

r.info, v.info, and g.region shell style output is probably
the most common of all modules used by users for scripting,
and must remain clear and to the point.


> Please don't revert the commits which are just against your
> *personal* taste!

reverting the units= vdatum= and title= *had* to be done, as
explained in an email of a few days ago. commit log message
explains the rest- not leaving it in a half and half mess of
concepts (I did try that first, but in testing the mess was
obvious). -g remains primarily for use with map bounds in
those modules, as it always has been, and that is not a bad
thing.

this does not make python scripting any more complicated,
it is just a matter of getting what you ask for instead of
the kitchen sink, and not messing with what wasn't broken.

I considered adding quotes (see r.timestamp) for free-form text
but do not think that quoting for bourne shell will be the right
solution for all cases, and it is better to just output verbatim
and let the user split on the first '=' in whatever language they
are using.


best,
Hamish