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.'
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:
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
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
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
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
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
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.
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
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
10 matches
Mail list logo