Bug 187574 - rhel3: sed y command will not accept the newline escape sequence
Summary: rhel3: sed y command will not accept the newline escape sequence
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sed   
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Petr Machata
QA Contact: Ben Levenson
Depends On:
Blocks: RHEL3U8CanFix
TreeView+ depends on / blocked
Reported: 2006-04-01 03:02 UTC by Michael Gilbert
Modified: 2015-05-05 01:32 UTC (History)
1 user (show)

Fixed In Version: RHBA-2006-0362
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-20 15:06:46 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0362 normal SHIPPED_LIVE sed bug fix update 2006-07-19 19:16:00 UTC

Description Michael Gilbert 2006-04-01 03:02:04 UTC
Description of problem:

the sed y command will not accept the newline escape (and probably other escape
sequences) because they are considered to be multiple characters.

Version-Release number of selected component (if applicable):

the version of sed distributed in red hat advance server 3.

How reproducible:


Steps to Reproduce:
1. open shell
2. $ echo test | sed 'y/t/\n/'
Actual results:
sed: -e expression #1, char 7: strings for `y' command are different lengths

Expected results:


Additional info:
can you direct me to a sed rpm that will easily install on redhat advance server
3 that does not suffer this bug?  thank you.

Comment 8 Red Hat Bugzilla 2006-07-20 15:06:46 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Comment 9 giuseppe bonacci 2006-07-27 14:54:02 UTC
escape sequences are not yet properly parsed in the replacement text 
when running in a non-multibyte locale.

in fact, the translation at sed/compile.c:1276 is performed only 
if (MB_CUR_MAX > 1) because of sed/compile.c:1246. 

as a consequence, sed behaviour depends on the particular locale chosen:

[root@green-ALT BUILD]# echo aka | env LANG=en_US.UTF-8 ./sed-4.0.7/sed/sed
a       a

[root@green-ALT BUILD]# echo aka | env LANG=en_US.ISO-8859-1 ./sed-4.0.7/sed/sed

[root@green-ALT BUILD]# echo aka | env LANG=C ./sed-4.0.7/sed/sed 'y,k,\t,'

does that make sense?

-- g.b.

Comment 10 Petr Machata 2006-07-31 08:16:25 UTC
Ignoring escape sequences in C locale is intentional, because of POSIX
compatibility.  The ISO-8859-1 locale puzzles me.  It may be for similar reason,
but I can't say right away.  I'll take a look at it.

Comment 11 giuseppe bonacci 2006-07-31 13:47:42 UTC
as far as I can tell, MB_CUR_MAX (in stdlib.h) is the maximum number of bytes composing a character in current locale's charset.  so its value is 1 in all single-byte character sets ---including ascii for C/POSIX and ISO-8859-1 for en_US--- and > 1 in UTF-8 for en_US.UTF-8.  the following code  #include <stdio.h> #include <stdlib.h> #include <locale.h>  int main() {     setlocale(LC_ALL, "");     printf("%d\n", MB_CUR_MAX);     return 0; }  outputs the following with my glibc (2.3.5) implementation:  $ for i in C en_US en_US.UTF-8 ; do env LANG=$i ./a.out ; done 1 1 6  as far as I know, translation of utf8 multibyte sequences can be done independently from escape-sequence parsing, because no ascii char can appear in a valid multibyte utf8 sequence.  I really don't know whether a POSIX locale should imply POSIX compliance. however, relying on MB_CUR_MAX might have unseen consequences, e.g. disrupting the test script in your last sed rpm source. ;-)  regards, -- giuseppe 

Comment 12 Petr Machata 2006-08-01 14:52:10 UTC
Please direct all further comments to #200663.

Note You need to log in before you can comment on or make changes to this bug.