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

[Hamish]

Michael wrote:
> Does this mean that we are abandoning the idea to
> have -g determine *how* out put is printed (i.e.,
> shell-script style) and use other flags to
> determine *what* is printed? 

no/yes/in practice it doesn't matter &/or resolves
itself with a natural solution so we are just
arguing over irrelevant abstractions and bike shed
colors at this point.

For one thing that was not ever actually decided.
For g.region it was _attempted_ (amidst unresolved
disagreement), and the result was a huge mess which
took some months to recover from. But in the end
and after all that pain it didn't really matter,
as we were able to please both POVs because -g
always implies -p. If someone wanted to think of it
like -gp they could do that, if someone wanted to
think of it as just a -g button to get a fixed
result, they could do that too (most of the time).
And we were all happy (AFAIK) and could move on to
more productive and important things.

If you want to think about -g being coded to imply
-p as the 'abandoning of the idea' of a strict and
exclusive context switch, then yes we did abandon
that shortly after the idea was first attempted
some years ago. To me that is just a harmless
compromise+convenience which doesn't break anything
for anyone else.


So now we have some modules (mainly r.univar) where
-g acts to change the nature of the output, and
most modules where you press that button you get a
fixed response and can think of the "why" of it
anyway you like.. Because typically you get the same
output from both ways of thinking of it: you use -g
when you want to get shell style output & it just
works. I have a hard time imagining users ever
being very confused by this minor distinction when
they get what they want from either way of thinking
about it. If you want to confuse users having a -g
concept switch which outputs nothing when used
alone seems like a great way to do it.


Since I have never fully understood the "-g should
be for shell script style only!" comments (because
that has never changed), the best I can figure is
that r.info and v.info's report-form output is being
interpreted in others' eyes as the "-p" flag (which
doesn't exist), and so the idea is that -g shows
everything that the report-form shows, but in
a more parsable format. Breaking that long list of
report-form variables into 3 or so bite sized and
conceptually grouped chunks just doesn't seem so
horribly controversial to me. but maybe I miss the
point.


r.info and v.info basically remain almost identical
in usage as they always have been. nothing much has
changed except a bit of cleanup and consolidation.


honestly this thing is such a non-issue and we have
so many real bugs we could spend our finite energy
and time on..


through flexibility comes strength,
Hamish