Same happens for me (OSX). I walked thru the script commands
manually, and it is indeed messing up on the first sed.
I see this in the sed man for Sed Regex info (OSX uses the BSD sed):
2. The escape sequence \n matches a newline character embedded in the
pattern space. You can't, however, use a literal newline
character
in an address or in the substitute command.
Later, for the s/ function, it says:
A line can be split by substituting a newline character into it.
To specify a newline character in the replacement string, precede
it with a backslash.
Putting a real newline after the \ does the trick:
g.list type=$type mapset=$mapset \
| grep -v '^-\+$' \
| grep -v "files available" \
| grep -vi "mapset" \
| sed 's/ */\
/g' \
| grep -v '^$' \
| grep "$search" \
| sort \
| sed -e "s/$/$MAPSET/"
On Sep 18, 2007, at 2:15 AM, Michael Barton wrote:
Wolf,
I just checked the 'binary' version against the source version of
g.mlist.
Both are identical.
There must be something problematic in the new code. Has anyone
else had
this problem?
Has this been tried on a Mac? I don't know what difference that
would make,
but maybe something... I do know there there are some differences
in Mac OS
X awk and Linux awk. I don't know about sed and bash.
Michael
On 9/18/07 12:01 AM, "Wolf Bergenheim" <[EMAIL PROTECTED]>
wrote:
On 18.09.2007 09:56, Michael Barton wrote:
I tried the new fast g.mlist and got very weird results. Running
g.mlist
rast returned mapnames like...
elevation.10mnrstrct.areasn
... instead of
elevation.10m
It seems there is a missing \ before the n somewhere in the code,
since
\ + n => \n = new line. Or then your compiler doesn't handle "\n"
properly.
--Wolf
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev