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.
On Mon, Dec 01, 2003 at 07:38:28PM +0000, Glynn Clements wrote:
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.
Note:
r.out.mpeg supports wildcards. Maybe this could be moved somehow into
the parser.
[...]
> 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.
> > 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.
r.out.mpeg supports wildcards. Maybe this could be moved somehow into
the parser.
That code (gee_wildfiles()) is a hack; it spawns an "ls" command via
system() to generate the list of filenames.
The issue isn't figuring out how to implement wildcard expansion;
that's easy enough to do without using system() hacks. The issue is
deciding how to make use of it within GRASS.
> > > It would be nice if r.series would accept wildcards for the
> > > input maps.
> > >
...
> > 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().
...
> > > e.g.
...
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
...
The issue isn't figuring out how to implement wildcard expansion;
that's easy enough to do without using system() hacks. The issue is
deciding how to make use of it within GRASS.
I'd just point out that it should have a check against MAXFILES.
[Maybe not in this case, I haven't studied how r.series works]
Moreover, it would be good to have MAXFILES defined globally, such as
with DEFAULT_BG_COLOR, etc.
src/raster/r.patch/cmd/nfiles.h:
---------------------------------------------------------------------
/* The number of cell files that can be patched together.
*
* All cell files will be opened at one time, so this number can not
* be arbitrarily large.
*
* Must be smaller than MAXFILES as defined in src/libes/gis/G.h which
* in turn must be smaller than the operating system's limit.
* (Given by `cat /proc/sys/fs/file-max` in Linux 2.4)
*/
I'd just point out that it should have a check against MAXFILES.
[Maybe not in this case, I haven't studied how r.series works]
Moreover, it would be good to have MAXFILES defined globally, such as
with DEFAULT_BG_COLOR, etc.
src/raster/r.patch/cmd/nfiles.h:
---------------------------------------------------------------------
/* The number of cell files that can be patched together.
*
* All cell files will be opened at one time, so this number can not
* be arbitrarily large.
*
* Must be smaller than MAXFILES as defined in src/libes/gis/G.h which
* in turn must be smaller than the operating system's limit.
* (Given by `cat /proc/sys/fs/file-max` in Linux 2.4)
*/
There isn't any inherent reason why there should be a maximum number
of files. G_open_cell_* could reasonably be changed to dynamically
[re]allocate the G__.fileinfo array. The OS doesn't have to have a
static limit.