Damian Keefe wrote:
Hi Folks
$DBI::VERSION = "1.609"
perl, v5.8.8 built for x86_64-linux-thread-multi
SHELL=/bin/tcsh
I'm not sure if this should be considered a bug in DBI or elsewhere,
but it has unpleasant consequences. Somewhere in the bowels of DBI,
SIGPIPE gets set to 'IGNORE'. It remains in this state after
disconnect(). If you then launch a second script using backticks and
this script contains a line like
my $first_line = `grep -v '#' $filename|head -n 1`; # to get the first
non-comment line
the shell which is invoked inherits the SIGPIPE = 'IGNORE' state. This
causes a
grep: writing output: Broken pipe
error as the grep tries to write to the head process which has exited.
It took me a while to work this out because of the way perl populates
the %SIG hash. It appears it only populates it once from the system
when it is first used in the script. If you run the script below with
the first print statement commented out you get
connected to dk_funcgen_classify_59_MEF
SIGPIPE=IGNORE
If you uncomment the first print statement you get
SIGPIPE=UNDEF
connected to dk_funcgen_classify_59_MEF
SIGPIPE=UNDEF
However, behind the scenes, something has changed SIGPIPE to IGNORE
and the %SIG hash has not been updated.
(my workaround is to explicitly reset SIGPIPE to 'DEFAULT' in the
second script)
cheers
Damian
I suspect you'll find its your driver library that ignores SIGPIPE as
AFAIK, DBI does not.
Oracle's OCI library changes some signal dispositions for sure and
sometimes SIGPIPE/SIGCHLD.
Martin
<snipped example code>
