<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Nov 3, 2013 at 11:14 PM, Nikos Alexandris <span dir="ltr"><<a href="mailto:nik@nikosalexandris.net" target="_blank">nik@nikosalexandris.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">Nikos Alexandris wrote:<br>
<br>
> > Is it possible to define a series of flags -cl -ch -mi -ma for a bash<br>
> > shell<br>
> > grass script, that g.parser will understand?<br>
<br>
</div><div class="im">Glynn Clements wrote:<br>
<br>
> No. G_parser() (and thus g.parser) follows Unix convention in its<br>
> interpretation of flags, i.e. "-abc" is equivalent to "-a -b -c".<br>
><br>
> The double-dash flags (e.g. --quiet) are all hard-coded; it isn't<br>
> possible for a module to define its own.<br>
><br>
> If single-character flags aren't suitable for whatever reason,<br>
> consider using a multi-valued option, e.g. "flags=cl,ch,mi,ma".<br>
<br>
</div>The reason is ease in understanding (here preferred more than ease of use!):<br>
<br>
center low, center high, minimum modulator, maximum modulator, minimum<br>
modulator 2, maximum modulator 2. Only of low and high as well as only one of<br>
min and max can be defined at a time. And, then, only of min2 and max2 and<br>
only if a "-2" flag has been given.<br>
<br>
I currently use:<br>
- l, h (which make sense for low, high<br>
- i, a for m_i_n and m_a_x... yeah, brilliant idea... I know :-/<br>
- n, x for mi_n_2 and ma_x_2... another brilliant idea :D<br>
<br></blockquote><div>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].</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I wonder how you dev's (strategically) select flag letters? Are there always<br>
some reserved letters?<br>
<br></blockquote><div>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).</div>
<div><br></div><div>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).</div>
<div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Vaclav</div><div><br></div><div>[1] <a href="http://lists.osgeo.org/pipermail/grass-dev/2013-October/065977.html">http://lists.osgeo.org/pipermail/grass-dev/2013-October/065977.html</a><br></div><div>
[2] <a href="http://osgeo-org.1560.x6.nabble.com/G7-parameter-standardization-n-count-min-minimum-etc-td5082250.html">http://osgeo-org.1560.x6.nabble.com/G7-parameter-standardization-n-count-min-minimum-etc-td5082250.html</a><br>
</div><div>[3] <a href="http://comments.gmane.org/gmane.comp.gis.grass.devel/55256">http://comments.gmane.org/gmane.comp.gis.grass.devel/55256</a></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In any case, thanks for all of the feedback. Nikos<br>
<div class=""><div class="h5">_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</div></div></blockquote></div><br></div></div>