you're right, i forgot about those two perl signals.
ashamed
martin
Stas Bekman wrote:
> Martin Haase-Thomas wrote:
>
>> perl sighandlers require the signal as their first argument. so i
>> assume that it may not be a good idea to call Carp::cluck(), as any
>> of the Carp methods expect strings. try typing as follows:
>>
>> $SIG{WARN} = sub { Carp::cluck ("received signal shift() at
>> line".__LINE__) };
>
>
> Sorry Martin, but this is incorrect. There is no signal SIGWARN.
> $SIG{__WARN__} and $SIG{__DIE__} are special perl "signal" handlers,
> which accept the string as the first argument (actually expect a
> list). This has no effect:
>
> perl -MCarp -le '$SIG{WARN} = sub { Carp::cluck ("received signal
> shift() at line".__LINE__) }; warn doh, doh'
> dohdoh at -e line 1.
>
> While this does:
>
> perl -MCarp -le '$SIG{__WARN__} = sub { Carp::cluck ("received signal
> shift() at line".__LINE__) }; warn doh, doh'
> received signal shift() at line1 at -e line 1
> main::__ANON__('dohdoh at -e line 1.^J') called at -e line 1
>
>
> The Carp::cluck trick is correct, unless someone somewhere redefines
> $SIG{__WARN__}.
>
>
>> martin
>>
>>
>> Tim Noll wrote:
>>
>>> Stas Bekman wrote:
>>>
>>>>> I know this is a pretty generic question, but if nobody knows a quick
>>>>> answer, I can get more specific in a later post. Under Apache
>>>>> 1.3.22 /
>>>>> mod_perl 1.26, even while using $SIG{__WARN__} = \&Carp::cluck, I
>>>>> keep
>>>>> getting "Use of uninitialized value." in the Apache error log, with
>>>>> absolutely no line number or back trace or anything else. Does
>>>>> anybody
>>>>>
>>> know
>>>
>>>>> what might cause this? Thanks.
>>>>>
>>>> Where did you set $SIG{__WARN__}? Try in startup.pl as early as
>>>> possible.
>>>>
>>>
>>> It's set in startup.pl, which is basically a modified version of the
>>> example
>>> from perl.apache.org/guide. It works beautifully for every other
>>> error I've
>>> come across, which is why this one is so curious. As I mention in my
>>> earlier
>>> follow-up to my own post, I eventually traced the problem to an
>>> incorrect
>>> driver string in DBI->connect. However, that doesn't explain (to me
>>> anyway)
>>> why I wasn't getting more detail in the error log. Perhaps I'll
>>> delve into
>>> DBI.pm, unless someone can explain this to me beforehand.
>>>
>>> -Tim
>>>
>>>
>>
>
>
>
--
http://www.meome.de
-------------------------------------------------------
Martin Haase-Thomas | Tel.: 030 43730-558
meOme AG | Fax.: 030 43730-555
Software Development | [EMAIL PROTECTED]
-------------------------------------------------------
