Re: people working in Greg's locale (+euro) & display of Unicode names

On 6/15/17 9:01 PM, Peter & Kelly Passchier wrote: > On 16/06/2560 03:11, Chet Ramey wrote: >> You still have to look at every character. The world isn't all UTF-8: >> there are character sets where multibyte characters include characters >> that are valid ascii (including, I suspect, `='). > > I

Re: people working in Greg's locale (+euro) & display of Unicode names

On 16/06/2560 03:11, Chet Ramey wrote: > You still have to look at every character. The world isn't all UTF-8: > there are character sets where multibyte characters include characters > that are valid ascii (including, I suspect, `='). I think supporting all kinds of other encodings besides UTF-8

Re: char-class rules & please show examples of int. locales that use diff. char-class rules

Chet Ramey wrote: On 6/15/17 3:04 PM, L A Walsh wrote: Two problems with locale-based rules are: 1) they differ based on local convention, potentially, even down to what "side of the street" you live on, and That's precisely what makes them valuable to users. --- But such

Re: people working in Greg's locale (+euro) & display of Unicode names

Chet Ramey wrote: On 6/15/17 11:22 AM, PePa wrote: On 15/06/2560 22:03, Chet Ramey wrote: I don't know other languages well enough to point one out, but I can easily imagine that a particular character is an "alphabetic" in, say, Mandarin, but doesn't exist in someone's en_US

Re: char-class rules & please show examples of int. locales that use diff. char-class rules

On 6/15/17 3:04 PM, L A Walsh wrote: > Two problems with locale-based rules are: > >1) they differ based on local convention, potentially, > even down to what "side of the street" you live on, and That's precisely what makes them valuable to users. >2) they don't account or allow for

Re: people working in Greg's locale (+euro) & display of Unicode names

On 6/15/17 11:22 AM, PePa wrote: > On 15/06/2560 22:03, Chet Ramey wrote: >> I don't know other languages well enough to point one out, but I can easily >> imagine that a particular character is an "alphabetic" in, say, Mandarin, >> but doesn't exist in someone's en_US character set. > > I though

RFE: File Descriptor passing and socket pair creation

Since the subject's come up - difficulties with /dev/tcp, no timeout feature, somehow a failure to interrupt it, etc.  I want to suggest an alternative.  I don't propose removing /dev/tcp from Bash (since it's been there quite a long time, people use it and I'm sure many people like it), but I

Re: char-class rules & please show examples of int. locales that use diff. char-class rules

Chet Ramey wrote: On 6/14/17 5:52 PM, L A Walsh wrote: Chet Ramey wrote: But people don't work in Unicode. They work in their own locale. Ok, I have my locale set to latin9 (iso8859-15). Attached is a pic ... I am less concerned with how glyphs display in a console than how

Re: Why does 'connect' take so long (sometimes) and can't be interrupted?

I can't think of what could cause this problem. The TCP connection code in Bash seems pretty straightforward, and in my experiments I was able to interrupt it even if it was waiting for the server to accept a connection, or waiting for an available slot in the listen queue. It's possible the

Re: Why does 'connect' take so long (sometimes) and can't be interrupted?

On Thu, Jun 15, 2017 at 10:36 AM, wrote: [...] > Description: > This is a little complicated and I can't give you full details on how > to > replicate it, since I don't fully understand it myself. But under > certain > circumstances, the following

Re: cygheap base mismatch detected

On Thu, Jun 15, 2017 at 1:19 PM, Eduardo Bustamante wrote: [..] > Please report this to the Cygwin folks. This is not a bash issue. Err, not the Cygwin folks. You seem to be using Cmder, so ask them.

Re: cygheap base mismatch detected

On Thu, Jun 15, 2017 at 11:30 AM, Jon Morris wrote: > Hi, > > Just tried to submit a bug, but bashbug command failed, so here is the > problem text. > > Thanks, > > Jon Please report this to the Cygwin folks. This is not a bash issue.

cygheap base mismatch detected

Hi, Just tried to submit a bug, but bashbug command failed, so here is the problem text. Thanks, Jon From: jonmorris To: bug-bash@gnu.org Subject: cygheap base mismatch detected Configuration Information [Automatically generated, do not change]: Machine: i686 OS: msys Compiler: gcc

Why does 'connect' take so long (sometimes) and can't be interrupted?

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown'

Re: people working in Greg's locale (+euro) & display of Unicode names

On 15/06/2560 22:03, Chet Ramey wrote: > I don't know other languages well enough to point one out, but I can easily > imagine that a particular character is an "alphabetic" in, say, Mandarin, > but doesn't exist in someone's en_US character set. I though you were referring to a character

Re: Patch for unicode in varnames...

I'll leave my progress on the Unicode identifiers patch here (or the PR in Github, if you fancy that: https://github.com/dualbus/bash/pull/2/files). I won't have much time to work on this for a few weeks, so it's up to you all to complete it :-) It has markers on the places where it needs work

Re: people working in Greg's locale (+euro) & display of Unicode names

On 6/14/17 8:54 PM, PePa wrote: > On 15/06/2560 07:13, Chet Ramey wrote: >> A character that is classified as an alphanumeric in a particular locale, >> but not in another, can lead to portability problems. That's what we're >> debating here, not how something gets displayed in a text editor. > >

AddressSanitizer: heap-buffer-overflow in shell_expand_line

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==7938==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c0bd00 at pc 0x55ae5ef673f0 bp 0x7ffd16140ec0 sp 0x7ffd16140eb8 WRITE of size 1 at

AddressSanitizer: heap-buffer-overflow in rl_kill_text

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==11018==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6070ccc0 at pc 0x559bb60f1be7 bp 0x7ffc36ec8710 sp 0x7ffc36ec8708 READ of size 8 at

AddressSanitizer: heap-buffer-overflow in rl_search_history

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==15910==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6110977f at pc 0x55794384fd88 bp 0x7ffd35b10720 sp 0x7ffd35b10718 READ of size 1 at

AddressSanitizer: global-buffer-overflow in rl_filename_completion_function

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==1098==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55e61a6b4c5c at pc 0x55e61a3426ca bp 0x7fff1820a300 sp 0x7fff1820a2f8 READ of size 4 at

AddressSanitizer: heap-buffer-overflow in rl_tilde_expand

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==472==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6110977f at pc 0x562befba4a14 bp 0x7ffdee172bb0 sp 0x7ffdee172ba8 READ of size 1 at

AddressSanitizer: heap-buffer-overflow in rl_delete

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==1736==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61109880 at pc 0x7f464da3a063 bp 0x7ffe86032fe0 sp 0x7ffe86032790 READ of size 115 at