bash=~ bug or feature
With bash 3.1.17(4)-release # [[ "abcd" =~ "^a" ]]; echo $? 0 With bash 3.2.17(3)-release # [[ "abcd" =~ "^a" ]]; echo $? # is this a bug??? 1 # [[ "abcd" =~ ^a ]]; echo $? 0 Is this a bug? Thanks, Jeff. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
"wait" builtin with argument stucks and eats 100% CPU after 4096th call
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHE
uname output: Linux no 2.6.18-4-686 #1 SMP Wed Apr 18 09:55:10 UTC 2007 i686
GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
"wait" builtin with argument stucks and eats 100% CPU after 4096th call.
Repeat-By:
Try this shell script:
#!/bin/sh
prev=
for((a=0;a<5000;a++))
do
{
#Spawn a child which does whatever.
echo >/dev/null
} &
echo "Waiting for $a (prev=$prev)..."
test "$prev" && wait "$prev"
prev="$!"
done
wait
echo 'Ok, no bug found here.'
After executing, it will stuck and eat 100% CPU until Ctrl+C:
...
Waiting for 4094 (prev=21846)...
Waiting for 4095 (prev=21847)...
Waiting for 4096 (prev=21848)...
/root/bashtest: line 11: wait: pid 21848 is not a child of this shell
Waiting for 4097 (prev=21849)...
Waiting for 4098 (prev=21850)...
Thank you for your time. Osicka.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Infinite loop and crash Linux via BASH command
In this site http://www.istf.com.br/vb/showthread.php?t=11153 (pt_BR)
there is a command and an explanation of as this simple command : (){
:|:& };: can crash the Linux completely. It would be interesting you
will correct this.
I don't know by this means (perhaps anybody here with bigger
experiences to can explain us) this simple command creates a job in
background and in loop that quickly consome all the processing. I
quizzed in my one suse 10 and really locked.
-
Consultecnica Engenharia e Consultoria Ltda
11 4587-2099 - Jundiai/SP Visite: http://www.consultecnica.com.br
(Este email foi verificado contra vírus e outros tipos de
programas maliciosos.)
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Infinite loop and crash Linux via BASH command
[EMAIL PROTECTED] wrote:
> In this site http://www.istf.com.br/vb/showthread.php?t=11153 (pt_BR)
> there is a command and an explanation of as this simple command : (){
> :|:& };: can crash the Linux completely. It would be interesting you
> will correct this.
You are reporting what is well known as a "fork bomb". This really
has nothing to do with the GNU Bash shell and is actually due to the
fundamental design behavior of the operating system. It is not
something that can be fixed in Bash.
Please read this reference for more information.
http://en.wikipedia.org/wiki/Fork_bomb
Bob
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Infinite loop and crash Linux via BASH command
[EMAIL PROTECTED] wrote: > I don't know by this means (perhaps anybody here with bigger > experiences to can explain us) this simple command creates a job in > background and in loop that quickly consome all the processing. Yes, because that's exactly what you're telling bash to do, if you run that command. If you don't want bash to do that, don't tell it to. This isn't a bug. It's just an example of the fact that any sufficiently powerful language will be able to express things you don't want to do. If the language were too limited to express anything you didn't want to do, it also wouldn't be able to express many things that you want to do. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash=~ bug or feature
Jeff Chua wrote: > With bash 3.1.17(4)-release > # [[ "abcd" =~ "^a" ]]; echo $? > 0 > > With bash 3.2.17(3)-release > # [[ "abcd" =~ "^a" ]]; echo $? # is this a bug??? > 1 > # [[ "abcd" =~ ^a ]]; echo $? > 0 > > Is this a bug? The behavior has been intentionally changed. Please see Bash FAQ item E14. Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash=~ bug or feature
> With bash 3.1.17(4)-release
> # [[ "abcd" =~ "^a" ]]; echo $?
> 0
>
> With bash 3.2.17(3)-release
> # [[ "abcd" =~ "^a" ]]; echo $? # is this a bug???
> 1
> # [[ "abcd" =~ ^a ]]; echo $?
> 0
>
> Is this a bug?
It is the intended behavior. See question E14 in the latest bash FAQ
(reproduced below). There has also been extensive discussion of this
issue on bug-bash; see the list archives for a record.
E14) Why does quoting the pattern argument to the regular expression matching
conditional operator (=~) cause regexp matching to stop working?
In versions of bash prior to bash-3.2, the effect of quoting the regular
expression argument to the [[ command's =~ operator was not specified.
The practical effect was that double-quoting the pattern argument required
backslashes to quote special pattern characters, which interfered with the
backslash processing performed by double-quoted word expansion and was
inconsistent with how the == shell pattern matching operator treated
quoted characters.
In bash-3.2, the shell was changed to internally quote characters in single-
and double-quoted string arguments to the =~ operator, which suppresses the
special meaning of the characters special to regular expression processing
(`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^', and `$') and forces
them to be matched literally. This is consistent with how the `==' pattern
matching operator treats quoted portions of its pattern argument.
Since the treatment of quoted string arguments was changed, several issues
have arisen, chief among them the problem of white space in pattern arguments
and the differing treatment of quoted strings between bash-3.1 and bash-3.2.
Both problems may be solved by using a shell variable to hold the pattern.
Since word splitting is not performed when expanding shell variables in all
operands of the [[ command, this allows users to quote patterns as they wish
when assigning the variable, then expand the values to a single string that
may contain whitespace. The first problem may be solved by using backslashes
or any other quoting mechanism to escape the white space in the patterns.
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/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Infinite loop and crash Linux via BASH command
> In this site http://www.istf.com.br/vb/showthread.php?t=11153 (pt_BR)
> there is a command and an explanation of as this simple command : (){
> :|:& };: can crash the Linux completely. It would be interesting you
> will correct this.
The halting problem is still unsolved, as far as I know. :-)
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/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
