Re: is this a bug?
On Nov 14, 2007 7:26 AM, naruto canada <[EMAIL PROTECTED]> wrote:
> function fact {
> local n=$1
> if [ "$n" -eq 0 ]; then
> return 1
> else
> fact $(( $n - 1 ))
> return $(( $n * $? ))
> fi
> }
>
> for i in `seq 0 11`; do
> fact $i ; echo $?
> done
>
>
> 1
> 1
> 2
> 6
> 24
> 120
> 208
> 176
> 128
> 128
> 0
> 0
>
> the results are wrong for 6 and above.
> is this a bug?
>
It's not a bug. the exit status of a command, the "return" of your
function, is limited to the numbers 0-255.
You need to either use the output of your function or a global
variable if you want more than that.
is this a bug?
function fact {
local n=$1
if [ "$n" -eq 0 ]; then
return 1
else
fact $(( $n - 1 ))
return $(( $n * $? ))
fi
}
for i in `seq 0 11`; do
fact $i ; echo $?
done
1
1
2
6
24
120
208
176
128
128
0
0
the results are wrong for 6 and above.
is this a bug?
history not restore stdout
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux libertad 2.6.22-2-686 #1 SMP Fri Aug 31 00:24:01 UTC 2007 i686 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 0 Release Status: release Description: history builtin command no reconect stdout if fail: $ history >new_out bad_argument -bash: history: bad_argument: numeric argument required in this case bash conect sdtout to new_out, nex history fail (with bad argumente) and never reconect to stdout. Repeat-By: $ history >new_out bad_argument
Some broken UTF-8 sequence causes bash to infinite loop.
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc'
-DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H
-I. -I. -I./include -I./lib -g -O2
uname output: Linux debian 2.6.22-3-k7 #1 SMP Mon Oct 22 22:51:54 UTC 2007 i686
GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.2
Patch Level: 0
Release Status: release
Hi,
When I `cd` to directory that contains broken UTF-8 sequence, bash stops to
working and eat 100% cpu resource.
Ctrl-C doesn't work, so I need to SIGKILL to stop bash.
I have confirmed this problem will occur in official bash-3.2 and Debian's
bash-3.1dfsg-8.
After some tests, source code review, and tracing using gdb, I found how to
reproduce this problem.
To reproduce this, run bash with ja_JP.UTF-8 locale (probably other locales
where MB_CUR_MAX is larger than 2),
and put broken UTF-8 sequence to PS1 environment variable:
$ LANG=ja_JP.UTF-8 bash
$ PS1="\202\314\217\244\220l"
Unfortunately, this will NOT always reproduces the problem.
It will sometimes stops bash, sometimes not.
I have tried to find a bug, and I think the function
_rl_find_next_mbchar_internal in lib/readline/mbutil.c seems to have small bug.
Here is _rl_find_next_mbchar_internal function:
size_t tmp;
...snip...
tmp = mbrtowc (&wc, string + point, strlen (string + point), &ps);
while (tmp > 0 && wcwidth (wc) == 0)
{
point += tmp;
* tmp is declared as size_t. (Note: size_t is unsigned type.)
* The return value of mbrtowc will put to tmp. (Note: mbrtowc returns -1 or -2
on error.)
* Since tmp is unsigned type, -1 will be treated as 0x.
So that tmp > 0 will be true even if tmp is -1 or -2.
* When mbrtowc returns error, the value of wc will not be valid,
so the return value of wcwidth(wc) will be undefined.
It can causes bash to infinite loop.
If wcwidth(wc) returns non 0, while {} block will be skipped, and problem
will not occur.
But if wcwidth(wc) returns 0, since tmp is -1(0x), point += tmp will
decreased point variable.
I think the condition "tmp > 0" is not correct to detect errors.
It should be replaced with like this:
while (!(MB_NULLWCH (tmp) || MB_INVALIDCH (tmp)) && wcwidth (wc) == 0)
With this change, bash doesn't stop anymore when I set invalid UTF-8 sequence to
PS1.
I suggest following patch to fix this problem.
--- bash-3.2/lib/readline/mbutil.c.orig 2007-11-14 06:09:23.0 +0900
+++ bash-3.2/lib/readline/mbutil.c 2007-11-14 06:08:29.0 +0900
@@ -128,12 +128,10 @@
if (find_non_zero)
{
tmp = mbrtowc (&wc, string + point, strlen (string + point), &ps);
- while (tmp > 0 && wcwidth (wc) == 0)
+ while (!(MB_NULLWCH (tmp) || MB_INVALIDCH (tmp)) && wcwidth (wc) == 0)
{
point += tmp;
tmp = mbrtowc (&wc, string + point, strlen (string + point), &ps);
- if (MB_NULLWCH (tmp) || MB_INVALIDCH (tmp))
- break;
}
}
Thanks,
--
Morita Sho <[EMAIL PROTECTED]>
Re: is this a bug?
> It's not a bug. the exit status of a command, the "return" of your > function, is limited to the numbers 0-255. It's 0-128, actually. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: history not restore stdout
> Machine Type: i686-pc-linux-gnu > > Bash Version: 3.2 > Patch Level: 0 > Release Status: release > > Description: > history builtin command no reconect stdout if fail: > > $ history >new_out bad_argument > -bash: history: bad_argument: numeric argument required > > in this case bash conect sdtout to new_out, nex history fail (with bad > argumente) and never reconect to stdout. Patch 20 to bash-3.2 should fix this. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: is this a bug?
> > It's not a bug. the exit status of a command, the "return" of your > > function, is limited to the numbers 0-255. > > It's 0-128, actually. Whoops, no, you're right. You just can't count on exit statuses greater than 127 not conflicting with processes exiting due to a signal, so practice is to limit exit statuses to 0-127. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: find help about 'read' built-in command
Mike Stroyan wrote: > 龙海涛 wrote: > > Bob Proulx wrote: > > > test=$(pwd) > > > echo $test > > By the way, the variable "$PWD" has the same current directory value > as "$(pwd)" . Yes, you have a point, but... Even though this is a bash list I still prefer to use standard constructs when possible and practical. Since $PWD is a bash specific feature (would require #!/bin/bash) I would still tend to use $(pwd) because that works both in bash and in POSIX shells (would be okay with #!/bin/sh). Bob
