[GRASS-dev] list organization of g.list output

Paul Kelly paul-grass at stjohnspoint.co.uk
Thu May 24 15:38:13 EDT 2007

On Thu, 24 May 2007, Paul Kelly wrote:

> On Thu, 24 May 2007, Francesco P. Lovergine wrote:
>> 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??

On further consideration, I decided to leave out the automatic bit and 
keep an option in the new function G_ls_format() {which I separated out 
from G_ls()} to specify the number of items to print per line. By default
it will use the minimum number of rows it needs but print columnwise first 
rather than rowwise first. The main reason to not detect automatically was 
for output in gis.m's gronsole.tcl - it isn't writing directly to a 
terminal there, but you still want the output to appear in neat columns.

I also updated g.list (in fact lib/gis/list.c) to use the G__ls() and 
G_ls_format() rather than doing everything itself. If someone wants to add 
an option to g.list for 1-column output it should be possible now (by 
changing the argument passed to G_ls_format()).

All updated now in CVS.


More information about the grass-dev mailing list