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...
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 h
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:
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 r
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
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 s
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.
>
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
co
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 una
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 mul
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
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 underst
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
> >
> > $
13 matches
Mail list logo
