Dr. Watson paid my perl script a visit. . .

MrCromeDome has asked for the wisdom of the Perl Monks concerning the following question:

This problem is an odd one. At least I think so. My typical development involves two machines: my Win2k desktop for development, and Windows NT Server 4.0 for production use. Both run Apache 1.3.20 and ActivePerl 5.6.1. In one of my scripts, I had the following snippet of code:

$legal_temp = $subdivision . "<BR>\n" . $legal;
[download]

This worked exactly as intended on my development station, but when I moved it to the production server, Dr. Watson would trigger and halt execution of my script when this line was reached. I checked the server error log for details (as always, I have warnings, strict, and CGI::Carp enabled) to find none. I executed the script from the command line to again find no errors or warnings. I took a look through the script before this line again and verified that $subdivision, $legal and $legal_temp were all defined prior to this line.

I was able to work around Dr. Watson by changing the line to read this:

$legal_temp = $subdivision . "<BR>\n";
$legal_temp .= $legal;
[download]

I'm not sure why this works, but it does. And not knowing why annoys me to no end :P

I have a similar situation with the following line:

$bodytext .= "<TR><TD align=\"left\">" . ($lcount > 0 ? "<HR>" : "") .
+ "<FONT size=\"2\">";
[download]

No warnings or errors, and all variables are defined prior to use. However, this line also triggers Dr. Watson. By changing it to this:

$bodytext .= "<TR><TD align=\"left\"><FONT size=\"2\">";
[download]

the Dr. will leave me alone.

Is there something obvious that I'm doing wrong here? Or is there a difference in how ActivePerl behaves on Win2k as opposed to NT4? I'm confused. . . . if someone can help/explain, it would be greatly appreciated.

Thanks!
MrCromeDome

Comment on Dr. Watson paid my perl script a visit. . . Select or Download Code

Replies are listed 'Best First'.
(tye)Re: Dr. Watson paid my perl script a visit. . . by tye (Sage) on Oct 04, 2001 at 18:39 UTC
You may want to tell Dr. Watson to enter the debugger and see if you can get a stack trace or a line number or at least a subroutine name where the error is happening. It sounds as if you can reproduce this problem easily (though only when launched by Apache), so it would be a good deed to help track down this bug so that it can be fixed. - tye (but my friends call me "Tye")	[reply]
Re: Dr. Watson paid my perl script a visit. . . by CubicSpline (Friar) on Oct 04, 2001 at 17:27 UTC
It might be helpful to know a little bit more about what values you have in those variables. Assuming that they're just string values, there should be no problem. I tested the exact syntax you used on my Winnt4 system with ActiveState build 628 (perl 5.6.1) and had no problems. Upon the face of it, it seems that the problem might be in having two . operators in the same statement. Does Dr. Watson catch you when you do this in other places? Sorry I can't be of more help.	[reply]
Re: Re: Dr. Watson paid my perl script a visit. . . by MrCromeDome (Deacon) on Oct 04, 2001 at 17:52 UTC
You're absolutely correct - the variables are just holding strings. I was beginning to wonder the same thing about having multiple . operators in the same statement, so I checked out my script a little more. There are places where I have multiple concatenation operators, but those statements consist of all variables, such as: `$script = $select . $from . $where . $order_by;` [download] Maybe it has something to do with multiple concatenations involving both literals and variables? Not altogether sure. Could be worth investigating on a *NIX platform (to make sure it's not ActivePerl specific). Thanks! MrCromeDome	[reply] [d/l]
Re: Dr. Watson paid my perl script a visit. . . by alien_life_form (Pilgrim) on Oct 04, 2001 at 18:17 UTC
I have no idea why you are being so senselessly hit, however, it cannot be the $foo . "foo" . $bar thing. I am doing this kind of stuff all over and if it were a problem I'd be toast. But I'm not (not yet, at least...). If I were you I'd check system stuff like service packs on the NT box. A signal handler may help in pinpointing the problem (like: local $SIGNAL{INTR}= \&handle_intr). If you have a debugger and you feel like building from source, you can debug the snafu.<p Rather generic advice, I know... Cheers, alf	[reply]