Bug 187574 - rhel3: sed y command will not accept the newline escape sequence
rhel3: sed y command will not accept the newline escape sequence
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sed (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Machata
Ben Levenson
:
Depends On:
Blocks: RHEL3U8CanFix
  Show dependency treegraph
 
Reported: 2006-03-31 22:02 EST by Michael Gilbert
Modified: 2015-05-04 21:32 EDT (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Michael Gilbert 2006-03-31 22:02:04 EST
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:

always

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:

es

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 11:06:46 EDT
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.

http://rhn.redhat.com/errata/RHBA-2006-0362.html
Comment 9 giuseppe bonacci 2006-07-27 10:54:02 EDT
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
'y,k,\t,'
a       a

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

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

does that make sense?

regards, 
-- g.b.
Comment 10 Petr Machata 2006-07-31 04:16:25 EDT
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 09:47:42 EDT
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 10:52:10 EDT
Please direct all further comments to #200663.

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