[Top][All Lists]

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

Re: \c escape within $'...' can produce mangled UTF-8

From: Chet Ramey
Subject: Re: \c escape within $'...' can produce mangled UTF-8
Date: Sat, 14 Aug 2010 16:19:57 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6

On 8/14/10 3:01 PM, Dmitry Groshev wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale'
> -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include
> -I./lib   -g -O2
> uname output: Linux wjlair #1 SMP Fri Aug 14 19:13:09 MSD
> 2009 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ AuthenticAMD
> GNU/Linux
> Machine Type: i686-pc-linux-gnu
> Bash Version: 4.1
> Patch Level: 0
> Release Status: release
> Description:
>         In UTF-8 locale (such as ru_RU.UTF-8), a \c escape within
> $'...' results in an invalid UTF-8 string if followed by an UTF-8
> character: ansicstr() in lib/sh/strtrans.c consumes and converts the
> character's first byte, leaving the rest of UTF-8 sequence as it were.

I'm not sure why you think this is a bug.  The \c escape is described
as converting to a control character; control characters are always a
single byte; the conversion to a control character therefore consumes
one byte.  It's not the business of $'...' conversion to ensure that
the result is a valid multibyte character string.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

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