Another reason to consider extending the functionality of g.list over improvements to the g.mlist script is that a C-module would run in a Windows environment and the script contains a lot of *nix-isms that could be problematic even with Mysys.
Michael On 9/10/07 7:20 PM, "Glynn Clements" <[EMAIL PROTECTED]> wrote: > > Hamish wrote: > >> I noticed parts of the script may be a bit fragile/inefficient, which is >> of concern for a module mainly intended as a scripting tool. >> >> - The script relies on "echo -n"; not portable? > > Nope. According to the official specification, echo doesn't accept any > switches. OTOH, the GNU version doesn't support the \c sequence. IOW, > there is no portable way to echo a string without appending a newline. > >> http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html >> >> >> + g.list type=$type mapset=$mapset \ >> + | grep -v '^-\+$' \ >> + | grep -v "files available" \ >> + | grep -vi "mapset" \ >> + | sed 's/ */\n/g' \ >> + | grep -v '^$' \ >> + | grep "$search" \ >> + | sort \ >> + | while read i >> >> - combine the groups of sequential greps into single calls with the \| >> "OR" expr. > > The second and third can certainly be combined that way, provided that > you can use (or not use) -i for both (which is probably the case). I'm > not sure whether you can include the anchors (^ and $) within a > branch. > > Hmm; this is wrong: > > grep -vi "mapset" > > Nothing (other than common sense) prevents you from creating a map > named "mapset". > >> - The `grep -v "files available"` will fail when translated, >> 'raster files available in mapset <PERMANENT>:' >> I assume the `grep -vi "mapset"` is there as a poor workaround for that. >> ("mapset" will not be as translated as often as "files available") :-/ > > One more reason why we need a g.list which isn't quite so "hostile" to > scripting. > >> Is there a standard C library fn we can call to get regex support? >> Direct pattern searching in g.list would be preferable; I agree that >> a DIY reimplementation is a lot more trouble than it is worth. (unless >> some standard GPL code is copied verbatim into a new G_regex() libgis fn)? >> things like r.out.mpeg have basic map-name matching capabilities already. > > For regular expressions, regcomp(), regexec(), regfree() and > regerror() are specified by POSIX.1. For shell "glob" patterns, > fnmatch() is specified by POSIX.2. None of these are specified by > either version of ANSI C, so we would need additional libraries for > Windows. __________________________________________ Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
