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

[Paul Kelly]

On Fri, 25 May 2007, Hamish wrote:

> Eric wrote:
>> While we're on topic, maybe a separator parameter like g.mlist? I've
>> always found that a very convenient feature.
>
> Francesco 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.
>
> why not just use g.mlist if you want those?
> if(!tty) too "tricky"?

It's not tricky to do it:
if(!isatty(fileno(stdout)))
but tricky I suppose that the output will be different depending on where 
the module is writing to, which should be avoided I think.

> Michael:
>> 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
>
> and that IS just g.mlist.
>
>
> Granted g.mlist is just a wrapper around g.list's output, and allowing
> g.mlist to work on a -1 preformatted list would make it much less brittle.
>
> e.g. with today's changes we need to test that g.mlist still works.

I just checked and it does. It means the filenames will come into it in a 
different order, but it sorts them anyway so the output should be just the 
same.

> Paul:
>> 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??
>
> $COLUMNS always seems to be problematic for me (rxvt). Hardcode at 76?
> see bug #1107   http://intevation.de/rt/webrt?serial_num=1107

In G_ls* the terminal width is determined using a call to ioctl(). It 
seems to work well on Unix where I've tested it. Do you think 76 might be 
a better default that 80 for systems where it doesn't work?

> Paul:
>> 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()).
>
> Making g.mlist that much simpler, or even redundant.
> (so /bin/sh not needed for that functionality)

Yes, when I think about it though there's no reason why all of g.mlist's 
functionality couldn't be added to g.list.

Paul