[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU sed 4.2.1 \x bug ?

From: Paolo Bonzini
Subject: Re: GNU sed 4.2.1 \x bug ?
Date: Fri, 03 Dec 2010 21:14:13 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.6

On 12/03/2010 08:53 PM, Matija Nalis wrote:

I'm using "GNU sed version 4.2.1", and I'm having issues with "\x" expansion
as folows:

If \x escape sequence in LHS resolves to some character which has special
meaning in sed LHS (like "^", "\", ...), GNU sed does not use it as
hex-escaped, but instead as if it was literaly that character.

For example:
echo 'a^c' | sed -e 's/\x5e/b/'
should produce output "abc" (as it does in "ssed" or "perl -pe"), but in GNU
sed it produces "ba^c".


echo 'a\\c' | sed -e 's/\x5c/b/'
should again produce output "abc", but in GNU sed it terminates sed with error:
"sed: -e expression #1, char 10: Trailing backslash"
(as it interprets it as "sed -e 's/\/b/'" and not as "sed -e 's/\\/b/'")

There are several more such problematic characters.

Proposed solution: all such \xNN escapes should be treated as if the characters
are really escaped, for example '\x5e' in LHS should be treated like '\^' and
not like special-meaning '^'.

I had noticed the bug in Debian. It's not too easy to fix since of course \x3C should be treated as < rather than \<.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]