[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
GRASS GIS
trac at osgeo.org
Sun Nov 30 06:48:39 PST 2014
#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
Cpu: Unspecified |
----------------------------------+-----------------------------------------
Comment(by glynn):
Replying to [comment:73 martinl]:
> another option could to my mind. To use 'raster3d' and modify the parser
in the way that it would support also 'rast' and 'rast3d' with appropriate
warning
I don't think that "rast" should generate a warning. We want the user to
be able to abbreviate option names when running commands interactively. At
the same time, it's preferable for scripts to avoid abbreviations, which
they can't do if the actual option name is itself an abbreviation.
Perhaps we should relax the rule relating to ambiguous abbreviations for
the case where one option name is a prefix of another?
At present, if a module has options named "raster" and "raster3d", "rast"
(or any other abbreviation of "raster") will be rejected as ambiguous. The
option-matching function has to explicitly check for the case where an
option name is given in full, otherwise even the unabbreviated option name
would be rejected as ambiguous.
The change wouldn't be trivial; the function can no longer simply count
matches, it has to record them. But as a side-effect of that, the error
message for ambiguous options could list all of the matches.
If we don't make that change, then we should try to avoid the situation
where one option name is a prefix of another. In particular, that
precludes "raster3d" or "rast3d".
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:75>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list