[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