[GRASS-dev] Re: [GRASS GIS] #1658: g.rename,
g.copy do not ask for --overwrite, they just do it
GRASS GIS
trac at osgeo.org
Thu May 17 01:57:58 EDT 2012
#1658: g.rename, g.copy do not ask for --overwrite, they just do it
-----------------------------------------+----------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.5.0
Component: Default | Version: svn-develbranch6
Keywords: g.rename, g.copy, overwrite | Platform: Linux
Cpu: x86-64 |
-----------------------------------------+----------------------------------
Comment(by glynn):
Replying to [ticket:1658 hamish]:
> discovered in devbr6, but may happen in other branches too:
In 7.0 SVN:
{{{
$ g.rename one,two
<two> already exists in mapset <glynn>
}}}
In 6.5, g.copy etc have the same logic (checking module->overwrite), but
it doesn't work correctly with 6.5's G_parser(), which needs
{{{
module_info.overwrite = 0;
}}}
at the beginning of the check_overwrite() function.
The overwrite field of the GModule structure serves two purposes:
1. If it is set by the module prior to calling G_parser(), the --o flag
will be listed in the --help (etc) output even if no options have "new" in
the gisprompt field. This is required for modules such as g.copy and
r.mapcalc which have output maps specified by means other than "output="
options.
2. It is set by G_parser() if the --o or --overwrite options were given,
the GRASS variable OVERWRITE is set to a non-zero value, or the
environment variable GRASS_OVERWRITE is set to a non-zero value.
In 7.0, G_parser() explicitly sets it to zero if --help or similar aren't
being used. 6.x doesn't do this, so setting it before calling G_parser()
to indicate that --o is accepted will result in it always being set upon
return from G_parser().
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1658#comment:1>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list