[GRASS-dev] g.list -a

[Martin Landa]

Hi,

it is nice idea but there is one problem. The data type list is common
for related modules, e.g. g.remove, g.copy, etc. It would affect them
also...

Martin

2007/1/3, Daniel Calvelo <dca.gis at gmail.com>:
> 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
>


-- 
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *