Hi,
Would it be difficult to add an option to use ‘map name exclusion patterns’ like is available in g.mlist?
In the meantime, is it possible to exclude maps using regular expression in g.mremove?
Best
Paulo
Hi Paulo,
There was no response in 5 days, you should create ticket for this,
otherwise we will forgot about it. I'm just adding some notes here.
On Wed, Mar 19, 2014 at 7:14 AM, Paulo van Breugel
<p.vanbreugel@gmail.com>wrote:
Hi,
Would it be difficult to add an option to use 'map name exclusion
patterns' like is available in g.mlist?
I'm always very confused when switching between g.mlist and g.mremove. The
parameters are almost the same, yet different.
g.mlist type=rast pattern="tmp_*"
g.mremove rast="tmp_*"
In the meantime, is it possible to exclude maps using regular expression
in g.mremove?Not sure, regular expressions are very bad at negative expressions/matches.
Vaclav
Best
Paulo
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Mon, Mar 24, 2014 at 7:04 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Wed, Mar 19, 2014 at 7:14 AM, Paulo van Breugel <p.vanbreugel@gmail.com>
wrote:Would it be difficult to add an option to use 'map name exclusion
patterns' like is available in g.mlist?I'm always very confused when switching between g.mlist and g.mremove. The
parameters are almost the same, yet different.g.mlist type=rast pattern="tmp_*"
g.mremove rast="tmp_*"
In the past, there was some discussion about this with a longer answer
from Glynn:
http://lists.osgeo.org/pipermail/grass-dev/2008-October/040506.html
Markus
Well, the g.mremove interface looks convenient, but can be dangerous also. For example, yesterday, I almost deleted my raster files by using the positional parameter thing while trying to delete all my temporary vectors.
g.mremove tmp*
Whops! 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. Like Glynn said, having separate parameters allows deleting different types of data, but its interface is long and not rush-to-hit-enter mistake free. 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. Wow! Total 24 pattern and exclude parameters. It’s also more coding and headache. I would like to suggest the following changes:
- Change g.mremove syntax to g.mremove type= pattern=
- Add exclude= to g.mremove.
- Replace g.remove/g.list with g.mremove/g.mlist.
Regards,
Huidae
···
On Thu, May 1, 2014 at 6:19 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Mon, Mar 24, 2014 at 7:04 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Wed, Mar 19, 2014 at 7:14 AM, Paulo van Breugel <p.vanbreugel@gmail.com>
wrote:Would it be difficult to add an option to use ‘map name exclusion
patterns’ like is available in g.mlist?I’m always very confused when switching between g.mlist and g.mremove. The
parameters are almost the same, yet different.g.mlist type=rast pattern=“tmp_*”
g.mremove rast=“tmp_*”
In the past, there was some discussion about this with a longer answer
from Glynn:
http://lists.osgeo.org/pipermail/grass-dev/2008-October/040506.htmlMarkus
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Fri, May 2, 2014 at 3:01 AM, Huidae Cho <grass4u@gmail.com> wrote:
Well, the g.mremove interface looks convenient, but can be dangerous also.
For example, yesterday, I almost deleted my raster files by using the
positional parameter thing while trying to delete all my temporary vectors.g.mremove tmp*
Whops! 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.
The easiest workaround is that we reorder the parameter list. At time we have
rast = 1st = default.
See
http://grass.osgeo.org/grass71/manuals/g.mremove.html
Putting there, say, "label" will enforce the user to have to set rast=
for deleting raster maps. This would require no extra efforts and
minimize the risk except for those using labels (so we could even add
a dummy parameter there. Or select another rather unknown parameter
from that list to become the first in the list).
Markus
Markus,
I think it’s good time to remove redundant modules and “sync” g.mlist and g.mremove parameters before releasing 7.0. Are there missing features from g.mlist/g.mremove that g.list/g.remove has?
Huidae
···
On Fri, May 2, 2014 at 10:47 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Fri, May 2, 2014 at 3:01 AM, Huidae Cho <grass4u@gmail.com> wrote:
Well, the g.mremove interface looks convenient, but can be dangerous also.
For example, yesterday, I almost deleted my raster files by using the
positional parameter thing while trying to delete all my temporary vectors.g.mremove tmp*
Whops! 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.The easiest workaround is that we reorder the parameter list. At time we have
rast = 1st = default.See
http://grass.osgeo.org/grass71/manuals/g.mremove.htmlPutting there, say, “label” will enforce the user to have to set rast=
for deleting raster maps. This would require no extra efforts and
minimize the risk except for those using labels (so we could even add
a dummy parameter there. Or select another rather unknown parameter
from that list to become the first in the list).Markus
On Fri, May 9, 2014 at 4:27 PM, Huidae Cho <grass4u@gmail.com> wrote:
I think it's good time to remove redundant modules and "sync" g.mlist and
g.mremove parameters before releasing 7.0. Are there missing features from
g.mlist/g.mremove that g.list/g.remove has?
One difference is the "more/less" stop option in g.list.
Perhaps g.list could become a Python wrapper around g.mlist and so on?
Markus
Markus,
The more/less stop option is already in g.mlist through -p/-f flags. These flags use the same code to output the same results.
Also, please check http://trac.osgeo.org/grass/ticket/2228. This version of g.mremove has the same interface as g.mlist.
Huidae
···
On Sun, May 11, 2014 at 4:27 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Fri, May 9, 2014 at 4:27 PM, Huidae Cho <grass4u@gmail.com> wrote:
I think it’s good time to remove redundant modules and “sync” g.mlist and
g.mremove parameters before releasing 7.0. Are there missing features from
g.mlist/g.mremove that g.list/g.remove has?One difference is the “more/less” stop option in g.list.
Perhaps g.list could become a Python wrapper around g.mlist and so on?Markus