[GRASS5] [bug #2238] (grass) r.series: support for wildcards in input filenames

[Glynn Clements]

Huddleston, John wrote:

> I did a search and found 558 uses of G_parser in the grass source.

That sounds about right; every non-interactive module should use it
(although a few don't).

However, so long as we don't change existing behaviour, it will only
affect modules which are explicitly changed to use the new features. 

[Aside: The G_parser() API (including G_define_option() and
G_define_flag()) is quite well suited to extensions; one can add new
fields to "struct Option" and "struct Flag" without having to change
all of the existing modules.]

My suggestion is to add a new type, e.g. TYPE_MAP, which would behave
like TYPE_STRING, except that G_parser() would do glob expansion on
existing map names when opt->multiple is set. r.series, r.patch and
r.out.mpeg would be prime candidates for using this extension. Such
modules would just need to use the new type.

Actually, there are prior suggestions for expanding the set of types
which G_parser() recognises. One of them is to have e.g. TYPE_OLD_MAP
and TYPE_NEW_MAP. Both would behave like TYPE_STRING; however,
TYPE_OLD_MAP would require that the map already exists (allowing
errors to be handled automatically by G_parser()), while TYPE_NEW_MAP
would require that the map doesn't already exist. In both cases, the
names would automatically be checked for legal names with
G_legal_filename().

TYPE_NEW_MAP is potentially problematic, as one might want to provide
an option to allow existing maps to be overwritten. However,
TYPE_OLD_MAP is straightforward enough. OTOH, it would be better to
have distinct types, e.g. TYPE_OLD_RASTER, TYPE_OLD_VECTOR etc.

-- 
Glynn Clements <glynn.clements at virgin.net>