"d.vect --help" still prints "where=name", but the html manual reads
"[where=string]" and "where=string".
Inconsistent.
I fixed that a few days ago in CVS.
http://grass.itc.it/pipermail/grass-commit/2005-December/019395.html
still different for integer,float vs. "value". shrug.
Besides, I agree with Hamish that "string" might be not the most
fortunate word here,
I don't think it is unfortunate, just obscure to non-programmers.
Anything better that doesn't confuse either beginners or power users?
Could the "string" here be replaced with sth like "sql_statement", or
"sql_query"?
Yes. "string" (or "value" for others) is just the default if the
option's ->type is defined as TYPE_STRING.
If you add a line to the option definition like:
option->key_desc = "sql_query";
you will get where=sql_query in the help usage, HTML, XML, and GUI
incarnations.
e.g. `d.barscale --help` gives "at=x,y" not "at=value".
In this case "where=" is a common option with specifics defined in
lib/gis/parser.c G_define_standard_option().
It would probably be good to do the same for the G_OPT_V_CATS standard
option too [d.vect cats= (v.extract list=range ??unfortunate)].
(both standard where= and cats= options modified in cvs just now.)
Hamish