#178: g.copy/g.rename help message
-------------------------+--------------------------------------------------
Reporter: hcho | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor | Milestone: 6.4.0
Component: default | Version: unspecified
Keywords: |
-------------------------+--------------------------------------------------
Currently, --o and --overwrite flags are automatically added to help
messages when the age of any gisprompt is new. g.copy and g.rename do not
define any such gisprompts and their help messages do not list the
overwrite flag, which actually works with these modules.
New users may not notice the availability of this flag for
g.copy/g.rename.
AFAICT, this is a limitation of the parser. The syntax of the various
options is <old>,<new> but the parser doesn't allow multiple ->gisprompt
settings.
BTW, neither the terminal interactive mode nor the GUI understand the
significance of the key_desc option.
I doubt that this can be changed given the current parser interface and
the way that g.copy/g.rename use it. Essentially, trying to use a single
option for multiple purposes (e.g. both input and output) tends to fail
for alternate modes (--help, --ui, etc).
The only way to make this work with the current parser interface would be
to have separate source and destination options for each type, with the
source labelled "old" and the destination labelled "new".
It would be nice to maintain a global list of cases which the parser
doesn't handle well (or at all), for reference when we get around to
designing a new type system for the parser.
Replying to [comment:1 glynn]:
> Replying to [ticket:178 hcho]:
>
> AFAICT, this is a limitation of the parser. The syntax of the various
options is <old>,<new> but the parser doesn't allow multiple ->gisprompt
settings.
>
> BTW, neither the terminal interactive mode nor the GUI understand the
significance of the key_desc option.
>
> I doubt that this can be changed given the current parser interface and
the way that g.copy/g.rename use it. Essentially, trying to use a single
option for multiple purposes (e.g. both input and output) tends to fail
for alternate modes (--help, --ui, etc).
>
> The only way to make this work with the current parser interface would
be to have separate source and destination options for each type, with the
source labelled "old" and the destination labelled "new".
>
> It would be nice to maintain a global list of cases which the parser
doesn't handle well (or at all), for reference when we get around to
designing a new type system for the parser.
#178: g.copy/g.rename help message
-------------------------------------+--------------------------------------
Reporter: hcho | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: minor | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: copy, rename, overwrite | Platform: All
Cpu: Unspecified |
-------------------------------------+--------------------------------------
Comment(by glynn):
Replying to [comment:2 lucadelu]:
> Is it possible to fix it for the GRASS 7 version?
I don't know what I was thinking in my previous reply. You can force a
module to list the --o flag by setting the "overwrite" field of the
GModule structure.