[GRASS-dev] proposal for g.search module
Vaclav Petras
wenzeslaus at gmail.com
Sat Nov 28 06:29:06 PST 2015
On Sat, Nov 28, 2015 at 5:09 AM, Jachym Cepicky <jachym.cepicky at gmail.com>
wrote:
> 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
>
> modules
> maps, groups
> mapsets
> locations?
> regions
> ...
>
Considering the fact that an important/main use case is interactive usage
in the command line, I now lean towards:
g.search.module aspect
g.search.data aspect
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*`).
> OR and AND flag
>
> terminal output, shell script output, json output
>
Yes, the default should be whatever is appropriate for the interactive use
in the command line.
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.
https://grass.osgeo.org/grass71/manuals/v.what.html
> this starts to be pretty heavy module :-)
>
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:
g.search.<type> <text>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151128/183865f7/attachment.html>
More information about the grass-dev
mailing list