I remember we had a long discussion in the dev group along the same lines years 
back. The result was to decide that -g should not print anything by itself, but 
should be a shell-script-style modifier for other flags that print information. 
For g.region, the main test case, the proper syntax for printing all relevant 
information should be g.region -gp (-g modifies the print flag -p)

However, for backwards compatibility, the stand-alone shortcut of g.region -g 
(= -gp) would be maintained through GRASS 6. In GRASS 7, this new syntax was 
supposed to be enforced (-g does nothing by itself). This way, we would not 
have these continuing discussions of what -g is supposed to print. This has not 
happened and so we are still having these discussions.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu




On Nov 15, 2011, at 10:00 AM, <[email protected]> wrote:

> Date: Mon, 14 Nov 2011 03:02:57 -0800 (PST)
> From: Hamish <[email protected]>
> Subject: [GRASS-dev] Re: [GRASS-SVN] r49205 - in grass/trunk:
>        lib/python      raster/r.info
> To: Martin Landa <[email protected]>
> Cc: GRASS developers list <[email protected]>
> Message-ID:
>        <[email protected]>
> Content-Type: text/plain; charset=us-ascii
> 
> 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

_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev

Reply via email to