[GRASS-dev] Does g.parser accept 2-byte flags?

[Nikos Alexandris]

Nikos Alexandris wrote:

> > > > Is it possible to define a series of flags -cl -ch -mi -ma for a bash
> > > > shell grass script, that g.parser will understand?


Glynn Clements wrote:

> > > No. G_parser() (and thus g.parser) follows Unix convention in its
> > > interpretation of flags, i.e. "-abc" is equivalent to "-a -b -c".

> > > The double-dash flags (e.g. --quiet) are all hard-coded; it isn't
> > > possible for a module to define its own.

> > > If single-character flags aren't suitable for whatever reason,
> > > consider using a multi-valued option, e.g. "flags=cl,ch,mi,ma".


Nikos A:

> > The reason is ease in understanding (here preferred more than ease of
> > use!):

> > center low, center high, minimum modulator, maximum modulator, minimum
> > modulator 2, maximum modulator 2. Only of low and high as well as only one
> > of min and max can be defined at a time. And, then, only of min2 and max2
> > and only if a "-2" flag has been given.

> > I currently use:
> >  - l, h (which make sense for low, high
> >  - i, a for m_i_n and m_a_x... yeah, brilliant idea... I know :-/
> >  - n, x for mi_n_2 and ma_x_2... another brilliant idea :D


Vaclav Petras:

> You can define option value as ``minimum_modular_1`` but then write only
> ``minmod1``. The system is now same as for option keys. See latest
> additions by Glynn described in *G7: parameter standardization: n/count,
> min/minimum etc* [1].

That certainly helps.


> > I wonder how you dev's (strategically) select flag letters? Are there
> > always some reserved letters?
 
> I personally use flags as a last possibility but of course they are
> inevitable. My problem with flags is that if you see the module call,
> you don't know what flag -s stands for (when I'm writing scripts with some
> other programs I can use long versions, e.g. --standalone-version).

You are right.  I have to reconsider.  Understanding is supported more by 
using options rather than using flags.  You know, I am a lousy wannabe-
everything who rarely reaches the level of doing-something :D


> The other problem is that you don't usually know what happens if the flag
> is not specified (e.g., what will be generated if "-s Generate standalone
> version" is not specified). This is the same criticisms as exists for
> checkboxes in GUI. This can be improved by good documentation/labels (e.g.,
> "-s ...otherwise document stub is generated).

Accepted.  However, I do work hard in this other direction, meaning I try to 
comment everyhing, as clear as possible.


> The last problem which I often see in GRASS modules and encounter myself is
> that you by default want some behavior, let's say "Register maps in
> temporal database". But here is the problem, how to disable this
> functionality? Using -t flag is strange "-t Do not register maps in
> temporal database" because -t as well as -r are suggesting action of
> registration. We unfortunately cannot write --no-temporal or --n-t.

This is why I thought of (trying to) use -cl, -ch, et.c. Anyhow, I have 
reached a working state for my script (really loaded with flags!). Will see 
how it works out. Maybe it'll be better with options.


> So, I don't use flags if possible and if I have to I don't see many chances
> to do it right, except for writing extensive label and description
> documentation. But maybe others see this more positively.

Personally I prefer to type less and see more (output, progress related 
messages).  Thank you Vaclav.  Nikos


> [1] http://lists.osgeo.org/pipermail/grass-dev/2013-October/065977.html
> [2]
> http://osgeo-org.1560.x6.nabble.com/G7-parameter-standardization-n-count-min
> -minimum-etc-td5082250.html [3]
> http://comments.gmane.org/gmane.comp.gis.grass.devel/55256