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 characters for bash-4.0. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
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/
*** ../bash-4.0/parse.y 2009-01-08 08:29:12.0 -0500
--- parse.y 2009-02-22 16:08:54.0 -0500
***
*** 3307,3311
/* Meta-characters that can introduce a reserved word. Not perfect
yet. */
! if MBTEST((tflags LEX_RESWDOK) == 0 (tflags LEX_CKCASE)
(tflags LEX_INCOMMENT) == 0 shellmeta(ch))
{
/* Add this character. */
--- 3307,3311
/* Meta-characters that can introduce a reserved word. Not perfect
yet. */
! if MBTEST((tflags LEX_PASSNEXT) == 0 (tflags LEX_RESWDOK) == 0
(tflags LEX_CKCASE) (tflags LEX_INCOMMENT) == 0 shellmeta(ch))
{
/* Add this character. */
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 block argument last command: ls Aborting...Abandon If /etc/bash_completion is suppressed, problem disapears. My bash_completion is : $Id: bash_completion,v 1.872 2006/03/01 16:20:18 ianmacd Exp $ Repeat-By: ls[space] [TAB] or cd[space][TAB] and several other commands. My fault; I dropped a line from a submitted patch. The attached patch corrects it for me; see if it works for you. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ *** ../bash-4.0/pcomplete.c 2009-02-01 17:12:31.0 -0500 --- pcomplete.c 2009-02-22 17:08:25.0 -0500 *** *** 1033,1036 --- 1033,1037 pps = ps; + save_parser_state (pps); begin_unwind_frame (gen-shell-function-matches); add_unwind_protect (restore_parser_state, (char *)pps);
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 come from an actual need? Was it requested by anyone? -- Stéphane
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 it abuses the C preprocessor to compile single-byte and multibyte versions of the matching functions. sm_loop.c provides the prototypes for the functions it compiles (internal_wstrmatch and internal_strmatch, each of which are defined as `FCT' before including sm_loop.c). this is a forward port of a patch for bash-3.2, but it seems the warning that existed in bash-3.2 doesnt exist in bash-4.0, so the patch isnt needed anymore -mike signature.asc Description: This is a digitally signed message part.
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 return value is an unsigned decimal integer:
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_24_01
but bash does not say that in the bash(1) man page ...
-mike
signature.asc
Description: This is a digitally signed message part.
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: return: -1: invalid option
return: usage: return [n]
POSIX states that the return value is an unsigned decimal integer:
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_24_01
but bash does not say that in the bash(1) man page ...
-mike
For the record, GNU bash, version 3.2.39(20)-release (i686-pc-cygwin)
behaves this way:
f() { return -1; }; f; echo $?
255
Which, burnt me the other day. I think I prefer the way bash 4.0
behaves because I would prefer to know that negative values are
illegal than to have them silently co-erced to the corresponding
unsigned integers . The bash 3.0 behaviour played havoc with a binary
search algorithm that I wrote until I realised that -1 had been
coerced to 255.
jon.
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 option parsing has broken that
$ f(){ return -1; }; f
-bash: return: -1: invalid option
return: usage: return [n]
POSIX states that the return value is an unsigned decimal integer:
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#t
ag_18_24_01
but bash does not say that in the bash(1) man page ...
-mike
For the record, GNU bash, version 3.2.39(20)-release (i686-pc-cygwin)
behaves this way:
f() { return -1; }; f; echo $?
255
right, every version of bash before 4.0 has treated n as a signed int and
masked it with 0xff. so -1 is 255, -2 is 254, etc...
Which, burnt me the other day. I think I prefer the way bash 4.0
behaves because I would prefer to know that negative values are
illegal than to have them silently co-erced to the corresponding
unsigned integers . The bash 3.0 behaviour played havoc with a binary
search algorithm that I wrote until I realised that -1 had been
coerced to 255.
i think people need notice and/or warning of behavior changes. and the
documentation needs to be explicit.
-mike
signature.asc
Description: This is a digitally signed message part.
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...
