<div dir="ltr">Markus,<div><br></div><div>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?</div>
<div><br></div><div>Huidae</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 2, 2014 at 10:47 AM, Markus Neteler <span dir="ltr"><<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, May 2, 2014 at 3:01 AM, Huidae Cho <<a href="mailto:grass4u@gmail.com">grass4u@gmail.com</a>> wrote:<br>

> Well, the g.mremove interface looks convenient, but can be dangerous also.<br>
> For example, yesterday, I almost deleted my raster files by using the<br>
> positional parameter thing while trying to delete all my temporary vectors.<br>
><br>
> g.mremove tmp*<br>
><br>
> Whops! Did I want to delete tmp* rasters or vectors? I forgot to add vect=<br>
> and my tmp* rasters were listed. Thanks to the -f option.<br>
<br>
</div>The easiest workaround is that we reorder the parameter list. At time we have<br>
rast = 1st = default.<br>
<br>
See<br>
<a href="http://grass.osgeo.org/grass71/manuals/g.mremove.html" target="_blank">http://grass.osgeo.org/grass71/manuals/g.mremove.html</a><br>
<br>
Putting there, say, "label" will enforce the user to have to set rast=<br>
for deleting raster maps. This would require no extra efforts and<br>
minimize the risk except for those using labels (so we could even add<br>
a dummy parameter there. Or select another rather unknown parameter<br>
from that list to become the first in the list).<br>
<span class="HOEnZb"><font color="#888888"><br>
Markus<br>
</font></span></blockquote></div><br></div>