[Replying here because composing substantial responses in a 10-line text widget with limited editing functionality and a single level of undo is too much of a nuisance.]
GRASS GIS wrote: > > > It compares the wrong mapsets here (G_mapset() should possibly not > > > used on the left side, see function remove_subgroup_files() of main.c > of i.group. > > > > AFAICT, you should be able to use [EMAIL PROTECTED] to acheive > the desired result. > > this is working but not practical. I could have generated the group some > years ago, for a normal user it's hard to find out this trick (yes, use -l > and such but...). But what? "i.group -l" seems like exactly the right approach. In any case, the existing behaviour (unqualified names are assumed to be in the current mapset) has been around since at least 5.3 (I don't have an older version to check). So this particular issue should really have a separate ticket (as an "enhancement"); it's quite distinct from the issue for which this ticket was originally opened. > Maybe: if a map appears only once in the list, remove it. Otherwise tell > the user to indicate the mapset. Treating the name as a wildcard is definitely a bad idea; just because there's only one match, that doesn't mean it's correct. At least resolving it using the mapset search path is consistent with the rest of GRASS, so it's less likely to (silently) have unexpected consequences. > > Beyond that: unless "landsat" is in the mapset search path, this isn't a > bug; you '''should''' have to explicitly specify the @landsat part. > > It's not obvious (see above). It may not be obvious; that doesn't mean that it isn't correct. Actually, it seems (to me) to be a lot more obvious than treating the name as a wildcard, given that's how every other module treats unqualified names. An unqualified name should only be considered as a typing shortcut, and only when you already know *exactly* which qualified name it's a shortcut for. Unqualified names aren't a substitute for knowing what you're doing (nothing is). > > OTOH, in the case where it '''is''' in the mapset search path, it's a > limitation of the imagery library. The I_find_* functions only ever look > for files in the current mapset (passing a qualified name to I_find_* will > generate an error if the @mapset part doesn't specify the current mapset). > > AFAIK the imagery library was written in the early days of GRASS, > apparently improvements from libgis were never integrated. In retrospect, I_find_* isn't relevant here. The names refer to raster maps, not to groups or subgroups. > > Unlike the G_find_* functions, the I_find_* functions don't have a > mapset argument, so the caller doesn't get the option of passing > G_mapset() instead of "" to prevent the use of other mapsets. Bear in mind > that the same functions are used for both input (where other mapsets may > be used) and output (where only the current mapset may be used). > > Could the G_find_* functions be used instead? In this specific case, G_find_* would be the correct function, as these are raster map names. For the I_find_* functions, I would tend towards adding a mapset argument. There aren't that many callers which would need to be changed, and a fair number of those are the I_fopen_* functions, which have separate _new and _old versions. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
