Huidae Cho wrote:
I've just uploaded g.xlist and g.xremove (C implementations of g.mlist
and g.mremove, no dependency on g.list/g.remove) to
grass-addons/general. To compile these addons, you need POSIX regex(3)
functions. They are super fast (native speed of g.list/g.remove)!
Please test these modules.
I needed to extend G__ls to filter out unwanted file names.
G_set_ls_filter is used to define a regular expression filter. If you
have better ideas to do this, please let me know.
I would prefer to avoid putting the regex stuff in G__ls().
It would be more flexible (and eliminate any portability issues) to
make the filter a callback function, e.g.:
typedef int ls_filter_func(const char * /*filename*/, void * /*closure*/);
static ls_filter_func *ls_filter;
static void *ls_closure;
void G_set_ls_filter(ls_filter_func *func, void *closure)
{
*ls_filter = func;
*ls_closure = closure;
}
const char **G__ls(const char *dir, int *num_files)
{
...
while ((dp = readdir(dfd)) != NULL) {
...
if (ls_filter && !(*ls_filter)(dp->d_name, ls_closure))
continue;
...
}
g.mlist etc would have the callback perform the regexec(), and pass a
pointer to the compiled regex_t as the closure argument.
This would keep the portability issues out of libgis, and also allow
the use of other filters, e.g. fnmatch() or name[0] != '.' .
If these changes to
libgis (ls.c, join.c, gisdefs.h, POSIX regex) are acceptable,
g.m?(list|remove) might be substituted with these modules (?).
The existing scripts cannot be removed unless the C versions can be
made to work on all platforms (I daresay there's a regex library for
Windows, but we still need configure tests, etc).
Also, a stylistic issue regarding main.c:
#define TYPES opt.type->answers
Avoid using preprocessor macros unless it's *really* necessary. While
macros may make the code look "neater", it's also makes it harder to
understand what's actually going on.
--
Glynn Clements <glynn@gclements.plus.com>
