unwanted warning "execute_coproc: coproc [$PID:.*] still exists"
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc -I/usr/src/packages/BUILD/bash-4.1 -L/usr/src/packages/BUILD/bash-4.1/../readline-6.1 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu' -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -dH -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -std=gnu89 -Wuninitialized -Wextra -Wno-unprototyped-calls -Wno-switch-enum -Wno-unused-variable -Wno-unused-parameter -ftree-loop-linear -pipe -fprofile-use uname output: Linux oct 2.6.37.1-1.2-desktop #1 SMP PREEMPT 2011-02-21 10:34:10 +0100 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-suse-linux-gnu Bash Version: 4.1 Patch Level: 10 Release Status: release Description: Warning "execute_coproc: coproc [$PID:.*] still exists" as it is implemented makes no sense. It appears in many situations where it is done intentionally and it is not easy to silence it. If writing values of PID and I/O channels does not overwrite old values, I see no reason to issue this warning. Repeat-By: coproc a ( cat ) coproc b ( cat ) bash: warning: execute_coproc: coproc [13690:b] still exists Fix: The warning should be issued only if the old process still exists AND array which should store the coproc data is not empty.
unwanted warning "execute_coproc: coproc [$PID:.*] still exists"
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc -I/usr/src/packages/BUILD/bash-4.1 -L/usr/src/packages/BUILD/bash-4.1/../readline-6.1 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu' -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -dH -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -std=gnu89 -Wuninitialized -Wextra -Wno-unprototyped-calls -Wno-switch-enum -Wno-unused-variable -Wno-unused-parameter -ftree-loop-linear -pipe -fprofile-use uname output: Linux oct 2.6.37.1-1.2-desktop #1 SMP PREEMPT 2011-02-21 10:34:10 +0100 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-suse-linux-gnu Bash Version: 4.1 Patch Level: 10 Release Status: release Description: Warning "execute_coproc: coproc [$PID:.*] still exists" as it is implemented makes no sense. It appears in many situations where it is done intentionally and it is not easy to silence it. If writing values of PID and I/O channels does not overwrite old values, I see no reason to issue this warning. Repeat-By: coproc a ( cat ) coproc b ( cat ) bash: warning: execute_coproc: coproc [13690:b] still exists Fix: The warning should be issued only if the old process still exists AND array which should store the coproc data is not empty (or only if the array is not empty).
Re: Unexpected behavior with TZ
Hello, 06/04/2011 15:18, Chet Ramey : Hello, While looking after the multibyte test, i notice a behavior with printf3.sub that surprises me. Apply the patches. Patch 5 addresses this. Chet I have applied the eight patches and the test works fine, sorry for the noise. I have studied a little the multibyte test and noticed that the locales specified with the LANG environment variable are not considered by the glibc's methods mblen and mbtowc (stdlib.h), called from the method asciicode (buitlins/printf.def) when the LC_ALL or LC_CTYPE environment variables are already set. The multibyte test is successful on my host if i have first unset LC_ALL and LC_CTYPE before running it. I 'm not fully familiar with POSIX specifications regarding locales, for now these specifications let me think that this behavior is expected and that the LANG environment variable is taken into account after the LC_* environment variables. Therefore, perhaps this could be a way to deal with this issue without (i hope) side effects on other archs : --- tests/printf2.sub.orig 2009-02-24 20:12:32.0 +0100 +++ tests/printf2.sub 2011-04-07 23:21:24.0 +0200 @@ -1,4 +1,6 @@ export LANG=en_US.UTF-8 +unset LC_ALL +unset LC_CTYPE case $(printf %d\\n \'Ã) in 192) exit 0;; On another point, the multibyte documentation on mblen and mbtowc mentions that these two methods maintains an internal shift state (probably a way to be able to operate with bytes streams). I have noticed the DECLARE_MBSTATE macro in the asciicode method and wonder if it is the way to guaranteed a clear initial state to the mblen and mbtowc method. As i see in the docs, a call to mbtowc(NULL, NULL, 0); resets the internal state but this is an overhead that was not required regarding the asciicode method ? Regards, Cedric.
