<div dir="ltr">Vasku,<div><br></div><div>IIRC, "-g" flag was introduced first time in 2007 for g.region module and only reason for taking "g" letter was, that "s" for "shell script" was taken (or some similar reason). AFAIK there was never defined official GRASS rule for using -g flag for parsable output as well as how the output should look like - people simple started to adopt it (like usually in GRASS).</div><div><br></div><div>Putting rule to developer guidelines for parsable output as well as promoting the "-g" flag for all modules would certainly be an option</div><div><br></div><div>Jachym</div></div><br><div class="gmail_quote"><div dir="ltr">po 22. 8. 2016 v 4:39 odesílatel Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 19, 2016 at 2:15 AM, Jachym Cepicky <span dir="ltr"><<a href="mailto:jachym.cepicky@gmail.com" target="_blank">jachym.cepicky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>no special reason for not listing the module description too, just did not came to my mind</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thanks. Good to know.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Just do it [1]</div></div></blockquote><div><br>While using the modified version, I actually realized that "shell script
style" usually produces key-value pairs which can which can be
evaluated by shell's eval or grass.script.parse_command. Not all modules
comply with this, e.g. `g.extension -g` produces multiple key-values
with same keys and order matters, so this must be parsed in a special
way. The result is actually exactly the information g.search.modules is
producing:<br><br>$ g.extension -g<br><div>...<br>name=v.habitat.dem<br>description=Calculates DEM derived characteristics of habitats.<br>keywords=vector,raster,terrain,statistics,sun,zonal statistics<br>name=v.in.gbif<br>description=importing of GBIF species distribution data<br>keywords=vector,geometry<br><br></div>`g.extension -l` produces list of modules in the same way as currently `g.search.modules -g` produces:<br><div><br>$ g.extension -l<br><br>v.habitat.dem<br>v.in.gbif<br><br></div><div>As a result, I don't know what to do with -g, at this point I would just replace the letter by -n (names only) or -s (short output with names only) and add -t for table output (that's in the attached patch). -g can go to renamed options for compatibility reasons for now.<br><br></div><div>For the future, we should try to keep in mind that g.extension and g.search.module should have unified interfaces and/or outputs. And more generally, we should define what -g "shell script style" means.<br></div> </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>J </div><div><br></div><div>[1] <a href="https://www.youtube.com/watch?v=ZXsQAXx_ao0" target="_blank">https://www.youtube.com/watch?v=ZXsQAXx_ao0</a></div></div><br><div class="gmail_quote"><div dir="ltr">čt 18. 8. 2016 v 20:32 odesílatel Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>> napsal:<br></div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hi Jachym,<br><br></div>the g.search.module -g flag (shell style output) outputs just names. Do you have a particular reason for it? My use case is something like that:<br><br>g.search.modules keyword="support" -g | sed -e "s/|[^|]*$//g" | sed -e "s/|/\t/g"<br><br></div>with the following desired output (name + keywords, description removed by sed):<br><div><br>g.version general,support,citing,copyright,version,license<br>t.support temporal,metadata,time<br>r.support raster,metadata<br>r.support.stats raster,statistics<br>r.out.gdal raster,export<br>v.out.ogr vector,export,OGR<br>r3.support raster3d,metadata,voxel<br>g.findetc general,map management,scripts<br>v.external vector,import,external,OGR,PostGIS<br>g.message general,support,scripts<br>g.tempfile general,support,scripts<br>v.support vector,metadata<br>r.external raster,import,external<br><br>I can actually see that outputting just module names can be advantageous in some cases. But I want to get something like, so I can throw sed and grep on it:<br><br>v.support|vector,metadata|Updates vector map metadata.<br><br></div><div>If we permit change of the interface, I think -g could do the output above. This would make the -g output more like the others: same information as by default and with -j, so we can even consider it fixing a bug.<br><br>The current output with -g can be generated with some other flag. -n* for "names only" perhaps?<br><br></div><div>Best,<br></div><div>Vaclav<br></div><div><br>* <a href="https://lists.osgeo.org/pipermail/grass-dev/2016-August/081556.html" target="_blank">https://lists.osgeo.org/pipermail/grass-dev/2016-August/081556.html</a><br></div></div>
</blockquote></div></div></div>
</blockquote></div></div></div></blockquote></div>