Re: {# - strange behavior
On Sat, 2009-02-21 at 17:37 -0500, Chet Ramey wrote:
> Antonio Macchi wrote:
> >
> > thanks... but parameters expansions and printf builtin works differently
> > about it...
> >
> >
> >
> >
> > $ locale | grep LC_CTYPE
> > LC_CTYPE="en_US.UTF-8"
> >
> > $ a=eèèèe
> >
> > $ b=e
> >
> > $ echo ${#a}
> > 5
> >
> > $ echo ${#b}
> > 5
> >
> > $ printf "*%-10s*" $a
> > *eèèèe *
> >
> > $ printf "*%-10s*" $b
> > *e *
> >
> >
> >
> >
> > is it ok?
>
> Yes, it's ok. Posix says that printf field widths are specified in number
> of bytes.
>
> Chet
>
... although POSIX isn't always the last word. Development!
Improvement! Is POSIX the way things ought to be in this instance? If
not, what backwards compatible ways of changing the situation are there?
Slightly off topic I know but the radical inside me doesn't let these
things lie!
Regards, Max.
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: bash-4.0: fix internal_swtrmatch() prototype issues
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). 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 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 [...] 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: mapfile usage
Stephane CHAZELAS wrote: > 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 > [...] > > Note that that minor bug is still in 4.0-release. Thanks; it's fixed now. > I still don't get the rationale behind that builtin. Does that > come from an actual need? Was it requested by anyone? It was requested and contributed by the bashdb folks. I suppose Rocky could weigh in on it. :-) 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: 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 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 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...
