The simple explanation is: when you define a sub X, do not put parens, () after the name.
That's it.
sub X(){} means something very different than just sub X{}.
I would go as far as to say that you never have to, and normally should not put any (....stuff...) after the sub's name.

-What you have done with shift is 100% correct.
-Maybe chomp() is not necessary, but it doesn't "hurt".
-A more important point for me is to indent the lines within the subroutine by either 3 or 4 spaces.

"Prototype failure" example:

#!/usr/bin/perl -w
use strict;

# This sequence works, although with a warning...
# because Perl hasn't yet seen subroutine X.

X("xyz");

sub X()  # this means that subroutine X cannot 
         # be called with any arugment at all.
         # sub X();      #is ok, 
         # sub X("abc"); #is not ok.
{
   my $input = shift;
   print "$input\n";
}

#this would fail to produce a result - program fails to compile
# X("abc");  
# because now that subroutine X() has been seen, it is understood
# that no arguments can be passed to it.

__END__
prints:
main::X() called too early to check prototype at C:\TEMP\prototypes.pl
+ line 4.
xyz
[download]

You're right, I didn't realize what the () were for.. I thought they were necessary anytime arguments are passed in. Looking back, I'll bet this has been the unknown source of some of my debugging frustration in the past.. Thanks for the helpful pointers! I usually have a healthy OCD for indenting, when I pasted the code it looked like the formatting got weird in the entry form, so i deleted the tabs..

so i deleted the tabs..

I would not use tabs within code! In the ancient days, decades ago, this was seen because it conserved bytes, one \t char instead of a bunch of space characters. A consideration if you are using paper tape! The problem is that how many spaces a tab character represents is variable - there is no "standard" for this.

In your editor, find the setting where it says "convert tabs to spaces" and use it. That way, you can still hit your tab button when entering code, but space characters are what actually goes into the file. That way your file will be portable and the formatting will look the same, provided that the other system is using a fixed width font -which is what you should be using for writing code.