[GRASS-dev] g.mlist as C implementation?

[Michael Barton]

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