Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
While we're on topic, maybe a separator parameter like g.mlist? I've always found that a very convenient feature.
~ Eric.
-----Original Message-----
From: grass-dev-bounces@grass.itc.it on behalf of Michael Barton
Sent: Thu 5/24/2007 1:51 PM
To: Markus Neteler; GRASS developers list
Subject: Re: [GRASS-dev] list organization of g.list output
On 5/24/07 8:28 AM, "Markus Neteler" <neteler@itc.it> wrote:
Hi,
we observed that the list output style of g.list isn't that
useful:
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
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 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()).
Thanks very much. I will now need to relook at how the custom select class
works in wxPython because this is a nicer way to get a list of maps than
listing from the CELL directory.
Michael
On 5/24/07 12:38 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:
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.
Paul
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
>> 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?).
Multi-column listing needs to know the width of the terminal. If
stdout isn't a terminal, "the width of the terminal" isn't meaningful.
Multi-column listing needs to know the width of the terminal. If
stdout isn't a terminal, "the width of the terminal" isn't meaningful.
Yes that's true. Although if it can't determine the width it will use a default of 80 characters, which looks quite nice in the default size of gronsole. 1 filename per line scrolled off the top of the screen and was less user-friendly to read. And for g.list anyway, it's now an improvement on the way it was before in that it will adapt the width of the listing to the terminal width if it can detect it - before this evening's change it always used a fixed width of 80.
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.
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??
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...
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??
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.
I realize that there have been problems with g.mlist on Windows and perhaps
other platforms from time to time.
However, IMHO, the ideal solution would be for g.list to simply have a new
argument that would accept wildcards and other things that g.mlist takes.
e.g.
g.list type=rast filter=landsat*
Michael
On 5/24/07 10:38 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Making g.mlist that much simpler, or even redundant.
(so /bin/sh not needed for that functionality)
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University