<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 28, 2015 at 5:09 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"><p dir="ltr">Vašku, if we agree on adding more search engines to g.search, I suggest to define the features and interface (--help output) now and I can start think about more generic concept of the code</p>
<p dir="ltr">modules<br>
maps, groups<br>
mapsets<br>
locations?<br>
regions<br>
...</p></blockquote><div>Considering the fact that an important/main use case is interactive usage in the command line, I now lean towards:<br><br></div><div>g.search.module aspect<br>g.search.data aspect<br><br></div><div>which is longer than g.search but unlike `g.search type=module`, g.search.* will be auto-completed. Also it is still simpler than the shortest possible equivalent with g.list (`g.list rast p=*aspect*`).<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir="ltr">OR and AND flag</p>
<p dir="ltr">terminal output, shell script output, json output</p></blockquote><div>Yes, the default should be whatever is appropriate for the interactive use in the command line.<br><br></div><div>Shell script is GRASS standard but I think we should support other standards as well. For complicated output JSON is appropriate. There is only one module AFAIK, v.what, which supports JSON output because the shell style was just not enough. Some projects also generate lightweight markups which is an interesting option. <br><br><a href="https://grass.osgeo.org/grass71/manuals/v.what.html">https://grass.osgeo.org/grass71/manuals/v.what.html</a><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir="ltr">this starts to be pretty heavy module :-) <br></p></blockquote></div>You are right, so perhaps the g.search.* approach is the way around it. We can solve each case individually but we will provide consistency because the basic syntax will be:<br><br></div><div class="gmail_extra">g.search.<type> <text><br></div></div>