[GRASS-dev] g.mlist as C implementation?

[Hamish]

> Hamish wrote:
> > I will have a look at merging Martin, Markus and Glynn's suggestions for
> > a flat output g.list flag. As the feature is needed for parsing, I'd
> > rather do it as a flag vs. a ncols= option which retains the text and
> > fancy format mapset underlines. I've never really known what the "g"
> > stands for, but as we use it a lot for parsable output, the flag will
> > be '-g' here too.
> > 
> > so it would look like:
...
> > G63> g.list -gf rast
> > map1 at user1:
> > map2 at user1:This map has a title
> > map3 at user1:
> > map_a at PERMANENT:Raw x,y,z data binned into a raster grid by cell min
> > map_b at PERMANENT:Land Use
> > map_c at PERMANENT:
> 
> According to G_legal_filename(), ":" is legal in map names (that won't
> work on Windows):
> 
> 	if (*s == '/' || *s == '"' || *s == '\'' || *s <= ' ' || 
>             *s == '@' || *s == ',' || *s == '=' || *s == '*' || *s > 0176) {
> 		fprintf(stderr, _("Illegal filename. Character <%c> not allowed.\n"), *s);
> 
> I'd suggest using a comma for the field separator.

I'm not crazy about commas as field separators as there's a good chance that
the map title has some in it and a poorly written script would easily do
something like "cut -d, -f2" and chop it in half. Same goes for using a single
' ' space.

My two preferred choices would be : or |.
 ":" mimics what we use for deg:min:sec separators and makes some contextual   

   sense as a sep.
 "|" mimics what we use for vector attribute column separators.

(trying to reuse ideas wherever possible for consistency's sake)

We could add : and | to the G_legal_filename() blacklist, even though that
could hurt backwards compatibility if the fn is used to test ,,old_map names.
Esp. that, as you point out, calling a map "C:" is problematic on Windows.
(my vote it is to do it after making sure that g.rename doesn't call
G_legal_filename() for the old map name)


Using "=" for the sep seems inappropriate as
- it looks funny in this context, and 
- "map at mapset=Some Title" wouldn't be reasonably used as eval `shell variable`.

If all options are deemed too ugly I guess we could use the old \t standby.




Having now looked at the g.list code all I can say is yuk. There's about 7
convoluted layers of abstraction and G_spawn()ing to executables with MINGW32
#ifdefs and pipe checking and "more" paging thrown in when AFAICT there really
only needs to be 2 or 3 layers of clean C functions.

general/manage/cmd/list.c
general/manage/lister/{cell|vector}  -> $GISBASE/etc/lister/*.exe
general/manage/lib/do_list.c
lib/gis/list.c
lib/gis/ls.c

seem like they could all be combined into just
  general/manage/cmd/list.c  +  lib/gis/ls.c


My idea was to do a new simple G_list_element_flat() fn in lib/gis/list.c
which just creates a G__ls() list then loops through and fprintf(out,)s the
name, optionally the mapset, and optionally the sep+map title*, then closing
'\n'.

[*] title only makes sense if element is cell or vector, silently set to ""
otherwise.

I'm not really sure, Martin's patch is fine but I don't see any way to extent
it to append "@mapset" and "[sep]Map Title" as G_ls_format() goes right to the
stream. My idea above kind of suffers from the same problem- It seems a bit
wrong to have the same function be so low level that it calls {G_}ls and so
high level that it evals the result to query the map title with. It's nice to
have a deep lib fn do the list but the dump to stdout has to happen after the
title query and appending.


I would like to avoid having the new fn rely on any of the lister stuff or
pagers if at all possible. Just send result to FILE*out. (maybe I'm just not
good enough in C to write my own custom function to use for the lister arg and
the solution really isn't that hard, just follow the 'g.list -f' example?)


So perhaps we could use this opportunity to simplify this part of the code?
  (about here's where I cry oceanographer not software engineer ;)

Implementing 'g.list -g' SHOULD just be a 5 minute job..... but it ain't.


Hamish



       
____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz