Re: Fwd: Non-upstream patches for bash (2014)

[tetsujin]

It seems a strange inconsistency, though: Double-quoted strings (and,
really, pretty much all other Bash syntax as far as I have seen)
recognize 0x81 0x5C as a two-byte character rather than treating 0x5C
as a backslash within the quoting syntax, but $'..' strings
unconditionally treat 0x5C as a backslash...  Is there any reason a
disparity like that would be desirable?

----- Original Message -----
From: chet.ramey@case.edu
To:"George" <tetsujin@scope-eye.net>, "Eduardo_A._Bustamante_López"
<dualbus@gmail.com>, <bug-bash@gnu.org>
Cc:<chet.ramey@case.edu>
Sent:Mon, 26 Jun 2017 11:04:42 -0400
Subject:Re: Fwd: Non-upstream patches for bash (2014)

 On 6/25/17 11:08 PM, George wrote:
 > On Sun, 2017-06-25 at 12:23 -0400, Chet Ramey wrote:
 >> On 6/24/17 1:41 PM, Eduardo A. Bustamante López wrote:
 >>
 >>> dualbus@debian:~$ LANG=zh_CN.GBK printf 'u4e57' | od -tx1 -An 81
5c It
 >>> looks like it doesn't detect that x81x5c is a single character,
and
 >>> instead treats the multibyte character as separate characters. 
 >>
 >>
 >> It's apparently not a single character in that locale.
 >>
 > 
 > Yes it is!
 > 
 > https://en.wikipedia.org/wiki/GBK
 > x81 x5C is a two-byte character from level GBK/3.

 OK. The terminal emulator I'm using simply doesn't render the glyph.

 > But unless I've misunderstood something, it seems to be behaving
correctly
 > already. At least, with the exception of within $'..' quotes.

 It is behaving correctly. $'...' works using bytes. You can get it to
 expand a byte sequence to a multibyte character using u or x, but it
 works on bytes and always has, just like in C. Since 0x5c introduces
an
 escape sequence, that's how it's treated.

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