Opened 6 years ago

Closed 5 years ago

#2228 closed enhancement (fixed)

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

Reported by: pvanbosgeo Owned by: grass-dev@…
Priority: normal Milestone: 7.0.0
Component: Default Version: svn-trunk
Keywords: g.mlist, g.list, g.mremove, g.mremove, interface Cc:
CPU: All Platform: All

Description

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.

Attachments (3)

main.c (6.0 KB) - added by hcho 6 years ago.
g.mremove new version with the g.mlist interface
g-mremove-main.diff (6.5 KB) - added by hcho 6 years ago.
New g.mremove diff
test_g_mremove.py (3.3 KB) - added by wenzeslaus 6 years ago.
test of the proposed version of g.mremove (tested)

Download all attachments as: .zip

Change History (12)

comment:1 in reply to:  description Changed 6 years ago by 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_*"

comment:2 Changed 6 years ago by hcho

Platform: UnspecifiedAll

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"

Changed 6 years ago by hcho

Attachment: main.c added

g.mremove new version with the g.mlist interface

comment:3 in reply to:  2 Changed 6 years ago by 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.

comment:4 Changed 6 years ago by hcho

Yes, it supports multiple maps

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

Attached is the diff.

comment:5 Changed 6 years ago by hcho

CPU: UnspecifiedAll
Version: unspecifiedsvn-trunk

Changed 6 years ago by hcho

Attachment: g-mremove-main.diff added

New g.mremove diff

comment:6 Changed 6 years ago by wenzeslaus

Keywords: g.mlist g.list g.mremove g.mremove interface added

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

Changed 6 years ago by wenzeslaus

Attachment: test_g_mremove.py added

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

comment:7 Changed 6 years ago by hcho

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

comment:8 Changed 6 years ago by hcho

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

comment:9 Changed 5 years ago by neteler

Resolution: fixed
Status: newclosed

All got backported to relbranch7, closing.

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

Note: See TracTickets for help on using tickets.