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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
