Re: {# - strange behavior

Antonio Macchi wrote: same problem with read... LC_CTYPE=en_US.UTF-8 $ read -n1 è $ hexdump -C (echo -n $REPLY) c3|.| 0001 è is two chars but read stops at the first I fixed read to understand multibyte

Re: bash-4.0 regression: escaping of semicolons in subshell

Mike Frysinger wrote: bash-4.0 mishandles this code while bash-3.2_p48 and earlier work fine: echo $(echo \;) Try the attached patch. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ ***

Re: free: called with unallocated block argument

p...@arcturus.universe wrote: Bash Version: 4.0 Patch Level: 0 Release Status: release Description: Problem with auto completion : ls[space][TAB] gives the follwing abort : malloc: /Users/chet/src/bash/src/parse.y:5561: assertion botched free: called with unallocated

Re: mapfile usage

2009-02-4, 19:59(+00), Stephane CHAZELAS: [...] Also, it looks like it should guard against seq 5 | mapfile -C echo -c0 That command above cannot be interrupted with Ctrl-C [...] Note that that minor bug is still in 4.0-release. I still don't get the rationale behind that builtin. Does that

Re: bash-4.0: fix internal_swtrmatch() prototype issues

On Sunday 22 February 2009 16:49:01 Chet Ramey wrote: Mike Frysinger wrote: the internal_wstrmatch() prototype should be moved to lib/globl/strmatch.h as more than just strmatch.c uses this function (smatch.c uses it as well). No. If you look at how smatch.c is compiled, you'll see that

Re: bash-4.0 regression: escaping of semicolons in subshell

On Sunday 22 February 2009 16:16:57 Chet Ramey wrote: Mike Frysinger wrote: bash-4.0 mishandles this code while bash-3.2_p48 and earlier work fine: echo $(echo \;) Try the attached patch. seems to work, thanks -mike signature.asc Description: This is a digitally signed message part.

bash-4.0 regression: negative return values

previous versions of bash would happily accept negative values ( treated as a signed integer and masked with like 0xff), but it seems some changes related to option parsing has broken that $ f(){ return -1; }; f -bash: return: -1: invalid option return: usage: return [n] POSIX states that the

Re: bash-4.0 regression: negative return values

On Mon, Feb 23, 2009 at 4:03 PM, Mike Frysinger vap...@gentoo.org wrote: previous versions of bash would happily accept negative values ( treated as a signed integer and masked with like 0xff), but it seems some changes related to option parsing has broken that $ f(){ return -1; }; f -bash:

Re: bash-4.0 regression: negative return values

On Monday 23 February 2009 00:25:57 Jon Seymour wrote: On Mon, Feb 23, 2009 at 4:03 PM, Mike Frysinger vap...@gentoo.org wrote: previous versions of bash would happily accept negative values ( treated as a signed integer and masked with like 0xff), but it seems some changes related to

Re: {# - strange behavior

Yes, it's ok. Posix says that printf field widths are specified in number of bytes. I've never red nothing about POSIX, but imho, in the past, char and byte was synonymous maybe last POSIX definitions are very old...