Opened 12 years ago

Closed 6 years ago

#178 closed enhancement (fixed)

g.copy/g.rename help message

Reported by: hcho Owned by: grass-dev@…
Priority: minor Milestone: 7.0.0
Component: Default Version: svn-trunk
Keywords: copy, rename, overwrite Cc:
CPU: Unspecified Platform: All

Description

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.

Change History (5)

comment:1 in reply to:  description ; Changed 12 years ago by glynn

Replying to 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.

comment:2 in reply to:  1 ; Changed 8 years ago by lucadelu

CPU: Unspecified
Keywords: copy rename overwrite added
Milestone: 6.4.07.0.0
Platform: All
Version: unspecifiedsvn-trunk

Replying to glynn:

Replying to 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.

Is it possible to fix it for the GRASS 7 version?

comment:3 in reply to:  2 Changed 8 years ago by glynn

Replying to 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.

Fixed for g.copy and g.rename in r47819.

comment:4 Changed 6 years ago by neteler

Checked today, ticket is solved. Closing.

comment:5 Changed 6 years ago by neteler

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.