Re: Proxy list fetcher

[grinder]

Not bad. There are a number of glitches that running under warnings and strictures would have picked up:

In sub show_help, the part "192.168.1.1:80@http" will try and interpolate a non-existent array named @http. You can avoid this by not using a double-quoted heredoc.

# Lets define the data structure for the proxy array
# ip/host, port, type, country, anon level, use
push @data, ["127.0.0.1", "8080", "http", "USA", "Anonymous", "0"];

The fact that you have to leave a comment to help people understand what the array contains leads me to conclude that you would be better served by a hash, to make the data structure self-documenting:

push @data, {
  host => '127.0.0.1',
  port => 8080,
  ... };

This lets you write print fileOUT "$data[$i]{host}:$data[$i]{port} later on instead of print fileOUT "$data[$i][0]:$data[$i][1] which is probably better, and saves you having to shuffle around magic constants should you for some reason have the burning desire to add a new element to the beginning of the array thereby throwing everything off by one.

sub stayinvis($format) { ... }

The above doesn't really do anything, at least not what you expect. Variables passed to subs are made available in the @_ array. All this is really doing is getting the compiler confused about prototypes.

our %info = ("version", "0.3", "format", "0", ...

The above is more idiomatically written as

our %info = ( version => "0.3",
    format => 0,
    anonymouns => 1,
    ...

... mainly because it shows more clearly what are the keys and what are their values, rather making them an indistinguishable bunch that only the compiler knows how to get right. Make it easy on humans too.

push @data, ["$1", "$2", "http", "$3", "$4", "$use_this"]

You don't need to interpolate the variables in double quotes, they'll do just fine without them.

Other than that, in terms of optimisation there's nothing much that needs to be done. $& is known to introduce slowdowns in code, but as you're dealing with lengthy http transactions anyway, it just does not matter here.

The best advice I can give is to stick around and read some code here. The best practices tend to become obvious after a while.

Oh and kudos to you for using some modules, rather than trying to do it all yourself. Big time savings there.