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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
