Re: GNU sed 4.2.1 \x bug ?

[Matija Nalis]

On Fri, Dec 03, 2010 at 09:14:13PM +0100, Paolo Bonzini wrote:
> On 12/03/2010 08:53 PM, Matija Nalis wrote:
> >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 \<.

Yes... the easy way out (relatively simple and not much coding) is just to
hardcode values that need to be escaped when parsing \x sequence (and
process the others the same way they're processed now - without escaping)...

The disadvantage of course is that if some other character becomes special
in the future, it would need to be added at not only one place, but two (and
by that time the then-maintainer would probably forget that it needs to be
done, leading to new bug :-)

There might be a better way (to have universal list of special characters,
so the future changes need only be entered at one place), but I have not
looked at GNU sed code, so I don't know if that would be feasable.

Matija
-- 
Opinions above are GNU-copylefted.