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

2017-06-26 Thread Chet Ramey
On 6/26/17 4:35 PM, tetsu...@scope-eye.net wrote: > > That's not a reason why this disparity is "desirable" IMO. It's not intended to be anything but an explanation of why things are the way they are: compatibility and backwards compatibility. -- ``The lyf so short, the craft so long to lerne.'

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

2017-06-26 Thread tetsujin
t only causes harm. If other shells also implement it this way, then those other shells are also broken, and I'll submit this as a bug to their projects, too. :) - Original Message - From: chet.ra...@case.edu To:, "Eduardo_A._Bustamante_López" , Cc: Sent:Mon, 26 Jun 2017 14:34:

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

2017-06-26 Thread Chet Ramey
On 6/26/17 12:46 PM, tetsu...@scope-eye.net wrote: > > 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 quotin

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

2017-06-26 Thread tetsujin
0x5C as a backslash...  Is there any reason a disparity like that would be desirable? - Original Message - From: chet.ra...@case.edu To:"George" , "Eduardo_A._Bustamante_López" , Cc: Sent:Mon, 26 Jun 2017 11:04:42 -0400 Subject:Re: Fwd: Non-upstream patches for bas

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

2017-06-26 Thread Chet Ramey
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 \x81\x5c is a single character, an

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

2017-06-25 Thread George
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 \x81\x5c is a single character, and > > instead treat

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

2017-06-25 Thread Chet Ramey
On 6/24/17 1:41 PM, Eduardo A. Bustamante López wrote: > I was looking through this old thread: > http://seclists.org/oss-sec/2014/q3/851 > > It looks like the issue reported in there is still there: > > dualbus@debian:~$ LANG=zh_CN.GBK printf 'echo \u4e57\n' |LANG=zh_CN.GBK bash > �\ > dua

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

2017-06-24 Thread Eduardo A . Bustamante López
On Sat, Jun 24, 2017 at 04:46:47PM -0400, George wrote: [...] > I'm not seeing the problem here (at least, not in Bash or ksh - mksh and zsh > seem to have gotten it wrong...) You are right. I should get some sleep. FWIW, the original claim is that having a locale-dependent parser is a problem.

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

2017-06-24 Thread George
On Sat, 2017-06-24 at 12:41 -0500, Eduardo A. Bustamante López wrote: > I was looking through this old thread: > http://seclists.org/oss-sec/2014/q3/851 > > It looks like the issue reported in there is still there: > >   dualbus@debian:~$ LANG=zh_CN.GBK printf 'echo \u4e57\n' |LANG=zh_CN.GBK bash

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

2017-06-24 Thread Eduardo A . Bustamante López
I was looking through this old thread: http://seclists.org/oss-sec/2014/q3/851 It looks like the issue reported in there is still there: dualbus@debian:~$ LANG=zh_CN.GBK printf 'echo \u4e57\n' |LANG=zh_CN.GBK bash �\ dualbus@debian:~$ LANG=en_US.UTF8 printf 'echo \u4e57\n' |LANG=en_US.UTF8