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

GRASS GRASS developer
1

Hi Glynn,

The g.parser usage is <filename> [<argument> ...]

For it to be changed the logic would be to loop through the arguments
until a non-file name occurs. Logic would have to be added to see if
any arguments remain. If this is acceptable design, I can add the code.

John Huddleston

-----Original Message-----
From: Glynn Clements [mailto:glynn.clements@virgin.net]
Sent: Monday, December 01, 2003 12:38 PM
To: Request Tracker
Cc: grass5@grass.itc.it%INTER2
Subject: Re: [GRASS5] [bug #2238] (grass) r.series: support for wildcards in
input filenames
Importance: Low

Request Tracker wrote:

It would be nice if r.series would accept wildcards for the input maps.

e.g.
r.series input=insitu_data.* output=insitu_data.stddev method=stddev

for:
insitu_data.001
insitu_data.002
...
insitu_data.052

That may also true for several other modules; in which case, it might be
better to figure out how to build this into G_parser().

such as the g.mremove script does. [0-9] expansions etc would be nice too,

but not critical.

g.mremove is a shell script, which makes implementing shell substitutions
somewhat easier.

glibc has the glob() function, which is apparently specified by POSIX.2,
although I would be reluctant to just rely upon its existence (e.g. it might
not be present on all platforms, or it may require an additional library).

For now I use a bash loop to set INPUT_MAPS=$INPUT_MAPS,next_map then
'r.series input=$INPUT_MAPS ...', but that sort of sucks.

Any reason not to activate this module for 5.3 yet?

Only the standard reason: once a module becomes "official", changing its
behaviour becomes problematic.

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

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

2

Huddleston, John wrote:

The g.parser usage is <filename> [<argument> ...]

For it to be changed the logic would be to loop through the arguments
until a non-file name occurs. Logic would have to be added to see if
any arguments remain. If this is acceptable design, I can add the code.

Sorry, I don't understand what you're saying.

What I was suggesting was basically:

1. Add an additional type, for use in the "type" field of
"struct Option", e.g. TYPE_FILENAME.

2. If an option had:

  opt->type == TYPE_FILENAME && opt->multiple

then G_parser() would do glob expansion, so in Hamish' example, using:

  input=insitu_data.*

would have the same result as:

  input=insitu_data.001,insitu_data.002,...,insitu_data.052

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