in reply to LWP::Useragent - why doesn't this code work? :/

At point ## 3 ##, you're relying on the value of $1 captured at point ## 1 ##; but you've re-used the regex engine in the split command at point ## 2 ##, which has probably overwritten it. Save the value of the captures immediately after they are captured.

if ($split[0] =~ m|(.*)//(.*)|) { ## 1 ## print $IN->header; #print qq|Got user/pass combo of: $2 \n|; my ($user,$pass) = split /\:/, $2; ## 2 ## $request = HTTP::Request->new(GET => qq|$1/$split[1]|); +## 3 ##

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^2: LWP::Useragent - why doesn't this code work? :/
by ultranerds (Hermit) on Jun 14, 2010 at 14:52 UTC
    Legend - that works! Thanks a ton!

    For anyone who may have the same issue, then please try:

    # if we have an @ in the URL, they will be giving us something lik +e ftp://someone:somewhere@doamin.com .. so we need to process this ap +propriatly.. my $request; if ($url_to_get =~ /\@/) { my @split = split /\@/, $url_to_get; # [ftp://user:pass] @ [do +main.com] # ok, lets try and get the bit after //, so we have the user/p +ass combo... if ($split[0] =~ m|(.*)//(.*)|) { my $URI = qq|$1//$split[1]|; print $IN->header; #print qq|Got user/pass combo of: $2 \n|; my ($user,$pass) = split /\:/, $2; $request = HTTP::Request->new(GET => $URI); $request->authorization_basic($user, $pass); print qq|Bla, got URL of: "$URI" <br />user: $user <br />p +ass: $pass <br /><br />|; #exit; } } else { $request = HTTP::Request->new(GET => $url_to_get); }

      ...but if the value of $1 was wrong (overwritten) at ## 3 ##, why did it revert to the correct value (http:) in the subsequent debug print in your original code??   Sure, it's good practice to store away captures early, but not doing so is unlikely to have been the issue in this particular case.