Re: Problem with array initialization in typeset.
Steven W. Orr wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i386 > OS: linux-gnu > Compiler: i386-redhat-linux-gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_FILE_OFFSET_BITS=64 > -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 > uname output: Linux saturn 2.6.10-1.770_FC3smp #1 SMP Thu Feb 24 14:20:06 EST > 2005 i686 athlon i386 GNU/Linux > Machine Type: i386-redhat-linux-gnu > > Bash Version: 3.0 > Patch Level: 14 > Release Status: release > > Description: > Array initialization seems to be broken from typeset The problem is actually double evaluation. In versions of bash through 3.0, the assignment statement ends up being expanded twice: once before typeset is called, and once by the array assignment code. This has been fixed for the next version of bash, and things work as you expect. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live...Laugh...Love 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: Running multiple processes using trap and kill -s
Sammo wrote: > 2.05b.0(1)-release > > I seem to be having problems with one of the examples in the Advanced > Bash Scripting Guide [1]. The script is supposed to start a specified > number of processes, and when each process finishes, it sends a trap > signal, which starts a new process. I think the script is correct, but > it's not working as expected. > > This is what is happening: The first process that finishes sends a > trap signal to $$, and a new process is started (as expected). But > when subsequent processes try to send the trap signal, they can't find > the process. Also, seems that the "wait" command is only waiting until > the first process finishes, instead of waiting for all of them to > finish. I don't see how this can work in a modern version of bash. If you start a non-zero number of processes, each of which will send SIGRTMIN back to the controlling shell when it finishes, at least one of those signals will arrive while `wait' is executing. Bash is POSIX-conformant in this regard: since SIGRTMIN is trapped, wait will terminate and the trap will be executed. Once wait terminates, control falls right through to the end of the script, and the remaining children lose their controller. I don't know when the script was written, and it's reasonable to assume that wait's behavior has changed over time to become POSIX-conformant. However, it's behavior is correct now and I doubt it will change unless POSIX does. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live...Laugh...Love 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
Bad PIPESTATUS when using eval with a pipe stored in a variable
The following script use eval with 3 pipes, 1st time with direct pipe on
the command line, and the 2nd time with a pipe in a variable.
In this second eval, the PIPESTATUS does not content 3 entries, but only 2.
cat <<'EOF' > eval_pipe.sh
#!/bin/env bash
set -u
eval echo 'titi' | grep toto | grep titi
ret_codes=(${PIPESTATUS[*]})
echo ret_codes=${ret_codes[*]}
aPipe='|'
eval echo 'titi' $aPipe grep toto | grep titi
ret_codes=(${PIPESTATUS[*]})
echo ret_codes=${ret_codes[*]}
EOF
chmod +x eval_pipe.sh
eval_pipe.sh
<<
ret_codes=0 1 1
ret_codes=1 1
>>
Could be reproduce with bash version 2.05b (all patch applied) on Tru64
Unix 5.1A, version 2.05b.0(1)-release on cygwin, ...
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
