[GRASS-dev] g.list -a

Daniel Calvelo dca.gis at gmail.com
Wed Jan 3 11:45:14 EST 2007


How about g.list type=any or g.list type=all?

2c.

On 12/28/06, Martin Landa <landa.martin at gmail.com> wrote:
> Hi,
>
> I have just one general (maybe a little bit silly;-) question. There
> are number of modules which follow this pattern:
>
> * there is one (determinative) parameter (e.g. type in g.list)
> * and the flag for all types (e.g. -a -- List all data types)
>
> I can see two distinct approaches:
>
> 1) the determinative parameter is requested
>
> -> usage: g.list -a type=
>
> This is more precise for parsing syntax of the module, I think. On the
> other hand a little bit confusing for the user.
>
> 2) the determinative parameter is not requested
>
> -> usage: g.list -a
>
> This construction is more clear for the user I hope. But it cause more
> problems for programmer -- there is a need to handle meaningless usage
> of the module, e.g. g.list -f (verbose listing).
>
> I am not sure which approach is better.
>
> Best regards, Martin
>
> 2006/12/27, Martin Landa <landa.martin at gmail.com>:
> > Hi,
> >
> > 2006/12/27, Glynn Clements <glynn at gclements.plus.com>:
> > >
> > > Martin Landa wrote:
> > >
> > > > > > I am trying to implement the wish [1]. I found a strange construction
> > > > > > in g.list module. The -f flag (full listing) calls the external
> > > > > > program $GISBASE/etc/lister/[cell|vector]. These little programs are
> > > > > > called only in g.list -f (I think).
> > > > > >
> > > > > > I rewrote g.list without calling any external program -- i.e. I moved
> > > > > > functions from lister directory to lib/lister.c. If there are no
> > > > > > serious objections I will commit it to CVS.
> > > > >
> > > > > Don't remove the existing functionality; add a new switch for using
> > > > > your built-in lister.
> > > >
> > > > this patch does not remove any functionality (AFAIK). The only change
> > > > is: the functionality of lister (programs) is moved to lib/lister.c. I
> > > > don't see any reason why to have this functionality (the -f flag)
> > > > outside of the g.list (/etc/lister/[cell|vector]). Maybe there is a
> > > > particular reason for this construction, please let me know. Thanks!
> > >
> >
> > > The user can install lister programs for other types and/or replace
> > > existing ones.
> >
> > OK, it makes sense to me (only it's hard to imagine an user how
> > installs other lister program instead of changing the code;-)
> >
> > > The point of -f isn't so much to provide specific additional
> > > functionality, but to allow the handling to be deferred to an external
> > > program.
> >
> > You are right, I have tried to change the patch in this way, not sure
> > if I am working with child process as I should have. In any case
> > g.list works:-)
> >
> > Martin
> >
> > > --
> > > Glynn Clements <glynn at gclements.plus.com>
> > >
> >
> >
> > --
> > Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *
> >
> >
> >
>
>
> --
> Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
-- Daniel Calvelo Aros




More information about the grass-dev mailing list