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.'
That's not a reason why this disparity is "desirable" IMO.
Generally, the rule is that the shell interprets the shell script it's
given according to the character set of the active locale. It may not
allow any given sequence of characters in any given context, but in
terms of how the parser trans
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
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 b
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
