...just in case, you want to run this under Linux, without explicitly calling perl from the commandline:

#!/usr/bin/perl
#!usr/bin/perl    # original post w/o a "/" ....
[download]

#!/usr/bin/env perl
[download]

So, you're saying if I add the extra "/":

#!/usr/bin/perl
[download]

when calling the program from the command line, I would no longer have to say "perl my_prog.pl", just "my_prog.pl" to run it?

Yes, I dare to say so ;-) But if that doesn't work, you might also need to check:

• sufficient execution (and reading) permissions: use chmod 755 my_program.pl or at least chmod u+rx my_program.pl to tell the OS that this file is a program
• a $PATH environment variable that contains . (current directory) or the directory your script is stored, e.g. $HOME/bin or ~/bin . Some consider adding "." to the PATH environment variable a security risk. Personally, I wouldn't care too much for an individual account on a private/non-production system (the system owned by you alone). Use echo $PATH to see your current settings. Add a line like export PATH=".:$PATH""$PATH:." at the end of your ~/.environment or ~.bashrc file (assuming you're using bash). Alternatively you can run your program like ./my_program.pl (if it is in the same directory). OR you save your program in a directory, that is already in your environments PATH variable - like ~/bin (~ is a shortcut for $HOME or /home/koolgirl/ or where your account might be located).
• /usr/bin/perl does really exist
• a file system mounted without 'noexec' attribute (usually the case)
• ... there are more, but the most likely stuff is listed above
I guess, most of these conditions are already met for your system, so all you need to do after editing your new Perl program is to do a chmod 755 my_program.pl once and run it as ./my_program.pl. See the PATH-comment if you insist on my_program.pl.

The original problem was that the missing slash prevented the system to find the perl binary which is usually located in /usr/bin/perl but not in usr/bin/perl . It might have worked when you cd to / first, but this is nonsense. Fix the first line and it can be started (potentially) anywhere.

Update: Argl, oko1 is right with the 644 - thanks - how could that happen? (s/644/755/)
In agreement with Oko1's comment the dot is put at the end of the PATH for slightly improved security. A mistyped command or a legal program name that is not within $PATH - or not installed at all - can be executed when injected into the (visited) local directory. The truely paranoid careful and responsible person will use the slightly inconvenient ./my_program.pl form (or install the program in a proper location) and never let a . enter the $PATH variable - an absolute no-no for root and other high previledged users. As said before, no good idea to do that (the dot thing) on a system accessible by other users.

I personally believe that you may be even more astonished to learn that under Windows (which works much with "extensions" that OTOH are in turn "mostly" an unexisting concept under *NIX) if you program is somewhere under %PATH% and .pl is included in %PATHEXT%, then you may just call you your program like my_prog. You will only have problems with one kind of shell redirection. But I don't think you care much...

--
If you can't understand the incipit, then please check the IPB Campaign.

Actually, it really isn't necessary, because I've been running into a lot of problems using this old version, so at the moment, I am looking to upgrade, though I haven't settled on anything, however, ActivePerl was recommended as a better starting point than Strawberry...any suggestions, on a specific dl, for a newer version of Perl to work with Win2000?

I would recommend getting the latest 5.10 release of whatever "flavor" of Perl you choose to use.