[GRASS-dev] list organization of g.list output
Paul Kelly
paul-grass at stjohnspoint.co.uk
Thu May 24 15:08:31 EDT 2007
On Thu, 24 May 2007, Francesco P. Lovergine wrote:
> On Thu, May 24, 2007 at 12:53:56PM -0400, Patton, Eric wrote:
>> For scripting, it would also be nice if it printed like this...
>>
>> aspect
>> basin_50K
>> boundary_county_500m
>> cfactorbare_1m
>> cfactorgrow_1m
>> elev_lid792_1m
>> elev_ned_30m
>> elev_srtm_30m
>> elev_state_500m
>>
>
> ls changes to single column when ever stdout is not a tty.
> That approach could be useful in the g.list case also I think.
That sounds like a good idea, although perhaps a little bit too much like
guessing what you want to do and doing it for you (isn't there ls -1 for
that?). I think the best way to handle this is to re-arrange the G_ls*
functions in lib/gis/ls.c to do whatever we need, and make lib/gis/list.c
use them. I already have a prototype working which does both the 1-column
output and Markus's preferred ordering, but am trying to decide if it's
worth adding an argument to some of the G_ls* functions to say how many
items to print per line, or if it should always be determined
automatically. The only thing I can think that a perline option would be
useful would be if you wanted 1-column output for this sort of thing - if
we made that automatic depending on where stdout was going might that be
enough functionality??
Paul
More information about the grass-dev
mailing list