in reply to program fails to get response that should be returned by UserAgent->post

Semi-OT, and re your first example code, you wrote, at line 51-52:
this used to be "print ($1)" but the warning about the undefined variable was annoying

Yes, a warning that one doesn't understand can be "annoying" but the underlying purpose is what's important. (It is not relevant here, but there are cases where one must turn off warnings to avoid meaningless annoyances, but -- as a general rule -- it's not a good plan to turn them off until you're absolutely sure why you're getting the warning and that turning warnings off for that segment is, in fact, the best way to handle the issue.)

In this case, your approach of changing the (valid!) variable for a capture, $1, to a literal "1" bears a family-resemblance to turning off warnings: it's an attempt to evade an annoyance without sufficient information about the effect of your change. What that change actually did was deprive you of a crucial clue to the problems.

After a few other items were changed (partly to acomodate windows; partly because of my inability to find "LWP 5.8" with ppm; and partly to fix failed declarations (like "my $browser....") (the last two caused compile errors when checked with perl -c altavista.pl), the "annoying" warning turned out to be Use of uninitialized value in print at altavista.pl line 53 which is your line 51.

The greedy .* may be the reason why the capture at your line 49 failed. $1..$9 are special variables for captures. Changing print ($1); to print (1); got rid of the very useful warning, here, by ignoring the attempt to capture data, and printing, instead, a literal "1" -- whcih is not what you were looking for.

Bottom line: It's not good practice (and defeats Perl's attempts to help you) to evade "annoying" warnings by fiddling with variables you don't understand nor by turning warnings off.

  • Comment on Re: program fails to get response that should be returned by UserAgent->post