Is it possible to define a series of flags -cl -ch -mi -ma for a bash shell
grass script, that g.parser will understand?
Is it "recommended" to use only 1-byte characters as flags?
Thank you, Nikos
Hi Nikos,
···
On Sun, Nov 3, 2013 at 11:19 AM, Nikos Alexandris <nik@nikosalexandris.net> 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?Is it “recommended” to use only 1-byte characters as flags?
I don’t think so. But maybe the option with type string and options defined would be what you can use?
Citing from r.in.wms script:
#%option
#% key: driver
#% type:string
#% description: Driver used to communication with server
#% descriptions: WMS_GDAL;Download data using GDAL WMS driver;WMS_GRASS;Download data using native GRASS-WMS driver;WMTS_GRASS;Download data using native GRASS-WMTS driver;OnEarth_GRASS;Download data using native GRASS-OnEarth driver;
#% options:WMS_GDAL, WMS_GRASS, WMTS_GRASS, OnEarth_GRASS
#% answer:WMS_GRASS
#% guisection: Connection
#%end
It could be more clearer than flags.
If g.parser supports that, there is a lot of bugs in GRASS… However, the documentation shows that Flag structure key attribute is only char (so one ascii character/byte):
http://grass.osgeo.org/programming7/structFlag.html
Try to define two byte flag, maybe it even triggers an error message.
Vaclav
Thank you, Nikos
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
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?
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".
--
Glynn Clements <glynn@gclements.plus.com>
Vaclav Petras wrote:
Hi Nikos,
Nikos Alexandris:
> Is it possible to define a series of flags -cl -ch -mi -ma for a bash
> shell grass script, that g.parser will understand? Is it "recommended" to
> use only 1-byte characters as flags?
I don't think so. But maybe the option with type string and options defined
would be what you can use?
[..]
It could be more clearer than flags.
I feel in this case of mine (so to say) it is nicer to have flags than
eventually writing "low" or "high" and "min" or "max".
If g.parser supports that, there is a lot of bugs in GRASS... However, the
documentation shows that Flag structure key attribute is only char (so one
ascii character/byte):
Thanks for the source.
Try to define two byte flag, maybe it even triggers an error message.
I tried already (some non-sense stuff -- as Glynn's e-mail confirms it is
impossible to use more than one character -- like):
key: {cl}
In any case, only the first character is read as a flag.
The cl, ch, mi, ma are like "center low", "center high", "minimum modulator",
"msximum modulator" Plus another two "minimum modulator 2" or "maximum
modulator 2".
It's hard to select single letters that are easier/directly linked to the
words min, max, min2, max2. Isn't it? :-?
I was slightly encouraged from ogr's flags "-al -so" :-). But, hey, c'est la
vie!
Nikos
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".
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 
I wonder how you dev's (strategically) select flag letters? Are there always
some reserved letters?
In any case, thanks for all of the feedback. Nikos
On Monday 04 of November 2013 06:14:03 Nikos Alexandris wrote:
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.
Well, only _one_ of... (I keep eating up words!).
N
On Sun, Nov 3, 2013 at 11:14 PM, Nikos Alexandris
<nik@nikosalexandris.net>wrote:
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".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 ideaYou 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].
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).
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).
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.
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.
Vaclav
[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
In any case, thanks for all of the feedback. Nikos
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
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
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
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