[GRASS-user] g.xlist/g.xremove addons (C version of g.mlist/g.mremove)

[Glynn Clements]

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 at gclements.plus.com>