g.mremove: add an option to use 'map name exclusion patterns' like is available in g.mlist

[pvanbosgeo]

It would be great if we could have an option in g.mremove to use 'map name exclussion patterns', similar to what is available in g.mlist.

On a related note, it would be good if g.mlist and g.mremove could use the same syntax (as suggested on the mailing list by Vaclav Petras). Now, we have:

g.mlist type=rast pattern="tmp_*"

g.mremove rast="tmp_*"

Perhaps there are good reasons for this, but from the user perspective, having the same syntax (and similar GUI interface) would be good.

[lucadelu]

Replying to pvanbosgeo:

It would be great if we could have an option in g.mremove to use 'map name exclussion patterns', similar to what is available in g.mlist.

On a related note, it would be good if g.mlist and g.mremove could use the same syntax (as suggested on the mailing list by Vaclav Petras). Now, we have:

g.mlist type=rast pattern="tmp_*"

g.mremove rast="tmp_*"

Perhaps there are good reasons for this, but from the user perspective, having the same syntax (and similar GUI interface) would be good.

I fully agree and I'd prefer the syntax of g.mremove with rast="tmp_*"

[hcho]

g.mremove has a bug that disallows the use of brace expansions. E.g.,

g.mremove rast="{sanderson,brady}_dem"

would not work because the pattern is split by comma first and two wildcard expressions "{sanderson" and "brady}" are both invalid. Since each option takes multiple map names, it cannot be avoided.

The attached g.mremove version addresses this issue and has the same interface as g.mlist (including exclude=, but except for mapset=, separator=, and output=, which are irrelevant). Please test it. I think we should push this version to trunk and possibly relbr7.

The attached version works like:

g.mremove type=rast pattern="{sanderson,brady}_*" exclude="*_f{acc,dem},sanderson_fdir"

g.mremove type=rast,vect pattern="brady_basin"

[hcho]

g.mremove new version with the g.mlist interface

[wenzeslaus]

Replying to hcho:

The attached g.mremove version addresses this issue and has the same interface as g.mlist (including exclude=, but except for mapset=, separator=, and output=, which are irrelevant). Please test it. I think we should push this version to trunk and possibly relbr7.

The attached version works like:

g.mremove type=rast pattern="{sanderson,brady}_*" exclude="*_f{acc,dem},sanderson_fdir"

g.mremove type=rast,vect pattern="brady_basin"

Is multiple map input still supported? I'm not sure how to remove multiple maps if I know their names considering that this version of g.mremove is used and g.remove will be removed. Now I do:

g.remove rast="mapone,maptwo,mapthree,mapfour,...,mapfifty"

The use case is a clean up function called at the end of the script which creates temporary maps.

Perhaps send also a diff for convenience of other who want to check your suggestion quickly.

[hcho]

Yes, it supports multiple maps

g.mremove rast pattern="mapone,maptwo,mapthree,mapfour,...,mapfifty"

Attached is the diff.

[hcho]

New g.mremove diff

[wenzeslaus]

I'm not able to inspect the patch but I tried to write a basic test for it. See the attachment. You can run it inside a sample NC location in user1 mapset using:

python test_g_mremove.py --verbose

Feel free to contribute more test cases if you have ideas.

Also, I just noticed that Luca actually wanted the g.mremove interface for g.mlist and for a moment I though I too but than I remembered that this this was already discussed on grass-dev with a clear result, so adding the main points here too.

​g.mremove: adding 'map name exclusion pattern' option (Huidae Cho):

The g.mremove interface looks convenient, but can be dangerous...
...deleted my raster files by using the
positional parameter thing while trying to delete all my temporary vectors.
    g.mremove tmp*
Did I want to delete tmp* rasters or vectors? I forgot to add vect=
and my tmp* rasters were listed. Thanks to the -f option.

... Also, if we want
to add the exclude= parameter to g.mremove, it's not just one but 12
because there are 12 data types and pattern parameters...

​g.mlist syntax vs g.mremove syntax (Glynn Clements):

...it's g.mremove (and g.remove, g.copy, g.rename)
which got it wrong. I'm aware that having a separate option for each
type means less typing, but...
the g.list/g.mlist interface makes for a smaller (and arguably
simpler) GUI dialog.

...g.mremove interface is basically a fudge to get
around the restriction that the parser only allows a single
"positional" parameter, and requires keywords for the rest. You can't
just use e.g.:
    g.mlist rast gpcp_1dd_p1d.*.*
but you can "fudge" it to:
    g.mlist rast=gpcp_1dd_p1d.*.*
by having a separate option for each type.

...using separate options means...
multiple remove/rename/copy operations in a single command. But I
wouldn't expect that usage to be particularly common...

[wenzeslaus]

test of the proposed version of g.mremove (tested)

[hcho]

If there are no objections, I'll change the current interface of g.mremove to that of g.mlist with exclude=.

[hcho]

I just submitted the new interface and related changes in python modules (r61009).

[neteler]

All got backported to relbranch7, closing.

(see ​http://grass.osgeo.org/grass70/manuals/g.remove.html)