You describe your problem as :

Each new loop that I wrapped the original code in required resetting some variables, which I was able to handle, but then I added another loop, to make a single instance of the script run over and over for different clients. Once one job is done, it waits for another request. I could have tried figuring out what variables needed to be cleared, but I could easily have missed something.

This is exactly the problem that block scoped ("lexical") variables, that is, variables declared with my solve for you:

use strict;
my @sites = qw(http://www.corion.net);
my $user_name = "Corion";
for my $user_site (@sites) {
  print "Summary for site $user_site\n";
  my $link_number; # = 0; # left the initialization out intentionally
  for my $link (get_site_links($user_site)) {
    print "$link_number: Found link $user_site$link\n";
    $link_number++;
  };
};

sub get_site_links {
  return qw(index.html test.html error.html);
};
[download]

Here, there is no need to reset the variables outside of their usage, as they won't be available, and for example $link_number will be reset to zero by Perl every time a new site loop is started. use strict; is there so that Perl can check for me whether I've used any of my block scoped variables only within the block I've intended to use them.

So, Perl already provides you with the tools, but you also have to use the right tool for the right problem...

Another, less good solution for your problem might be the local keyword, which allows you to temporarily assign a different value to a variable and Perl automagically restores the previous value when you leave the block of the local declaration, but for the problem you specified, lexical variables are the best solution.

PerlMonks is a discussion community, not a publishing tool, so it's hard to declare that this kind of discussion is out of line.

It sounds like you accept that the internal design of your LinkStructor script is sub-optimal. (If you'd known the requirements up front, you would have done it differently.) I understand that you don't think it's worthwhile to rewrite the script to improve the design. (Refactoring advocates would argue that you would have been better off making the changes throughout the development process, but that ship has sailed.)

In that context, the VarStructor function is an interesting hack, as a one-off, to keep that script running. If your posts had included a disclaimer that explained this context, I believe the reaction would have been more positive than negative. (Ex, replacing "Alternative to Perl's reset function, with extra features." with "I used this trick to add functionality to an in-house application; rather than rewriting the code using structured design techniques, I had it review its own source code to find variable names.")

But without that caveat, you should expect that other monks will question the applicability of the code you're posting -- it's like showing up at a medical conference to demonstrate your new, patent-pending Hand2HeadStapler -- you've got to expect that people are going to ask why you would want to staple your hand to your head, and suggest that you find another way to approach the problem.