Description of problem: .qa.[root@i386-3as tps]# echo aka | sed 'y,a,\\,' sed: -e expression #1, char 7: strings for y command are different lengths Version-Release number of selected component (if applicable): sed-4.0.7-9.el3.i386 How reproducible: always
Created attachment 152905 [details] Fix for RHEL-3 Fix for this problem. $ locale | grep LANG LANG=C $ echo abcd | ./sed-4.0.7/sed/sed 'y,abcd,\\\t\,!,' \ ,! $ locale | grep LANG LANG=cs_CZ.utf8 $ echo abcd | ./sed-4.0.7/sed/sed 'y,abcd,\\\t\,!,' \ ,! Also works the other way around: $ echo -e '\\\t,!' | ./sed-4.0.7/sed/sed 'y,\\\t\,!,abcd,' abcd
escaped characters are hopelessly buggy ... .qa.[root@ia64-3as tps]# echo -e 'ata' | sed 'y,t,\k,' sed: -e expression #1, char 7: strings for y command are different lengths .qa.[root@ia64-3as tps]# echo -e 'ata' | sed 'y,t,\x,' axa .qa.[root@ia64-3as tps]#
This: echo -e 'ata' | sed 'y,t,\x,' behaves as expected. \x is "hexadecimal escape", given sane argument: $ echo 'xyz' | ./sed-4.0.7/sed/sed 'y/y/\x20/' x z If the argument is not provided, backslash is simply ignored. This is consistent with latest upstream. E.g. echo does something similar: $ echo -e 'a\x20\x' a \x The \k case is resolved by the attached patch in a manner consistent with upstream: unresolved escapes are taken as if backslash was not there.
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.