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" <wolf+grass@bergenheim.net> 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