Next time you might try posting in smaller gulps. There is a lot here to comment on. Just post your immediate problem, demonstrate your best attempt, tell what the input and output are, mention any error messages, and tell us where you looked in the docs or on Perl Monks for enlightenment (so we know you made an honest try to dope it out).

I strongly encourage you to indent your code. It will show you things you are not seeing and it makes it much easier for both you and us to quickly grasp the flow and logic of what you are trying to do. Many sources recommend a 2 to 4 space indent. (So of course I use 3.) Like this:

while(<FILE>) {
   flock(FILE, 2); 
   @line = split(/ /, $_); 
   $itemDB = $line[0]; 
   if ($itemDB eq $item) {
      $found++ 
   }
}
[download]

Regarding comments: Try not to comment in a way that simply duplicates what your code says. This becomes a crutch and actually makes it harder for you to learn to look at the code and "see" what it is doing just by reading it. On the other hand, not duplicating the meaning of your code in a comment, helps you to code in a way that is more clear in the first place. Comments are for explaining why you did something non-standard, marking chunks of code, summarizing the purpose of a block of code, etc.

And in at least two places, your comments (which appear to be simply a restatement of the code) incorrectly describe what the code is doing. So if you are reading the comments to see what is happening, you will be misled.

And if you use indenting of blocks, you don't need the 'end if' or 'end while' comments unless the block is more than a screen long. The relationship of the end curly and the block it ends is clear visually.

Next, to your questions.

1. The default pattern for split is whitespace (i.e. \s) which includes \t. And note that it is back-slash and not forward-slash as you had it.

2. I will not comment the need for flock but I will point out that in both examples you are locking the file many times but only unlocking it once. This is the kind of thing that becomes more clear when you indent.

3. Writing to a file with a tab delimiter is just like writing anything else:      print OUTFILE "$var1\t$var2\t$var3\n"; or perhaps      print OUTFILE $ary[0] . "\t" . $ary[1] . "\t" . $ary[2] . "\n"; There are ways to get fancier than that, but they can come later when you are more confident. Be careful not to use single quotes around the \t. That will just give you a literal back-slash and a 't'. Not a tab.

4. I'm not sure exactly what you mean here so I'll leave that for someone else or a follow-up by you.

Second Example: (again this is something that indenting would make clear) near the end you use a curly bracket to close the 'else' and then you close the 'if'. But you already closed the if block right before the word 'else'. This kind of error can sometimes cause errors at some distance from the source of the problem. In this example the curly labeled '#end if' actually closes the 'while' block. Not what you intended at all. And if there were lots of code between the end of the if block and the real end of the while block, the resulting error msg might be hard to make sense of.

Yes you can escape from the loop early. Here's an example that also includes a split on tabs:

while(<FILE>) { 
   @line = split(/\t/, $_);
   $itemDB = $line[0]; 
   if ($itemDB eq $item) {
      &Sub1();
      last;             # <----
   } else {
      &Sub2();
   }
}
[download]

Good luck. Breath easy... Small gulps.... And keep in touch. ;-)

------------------------------------------------------------
"Perl is a mess and that's good because the
problem space is also a mess." - Larry Wall

Well first of all I'd like to thank everyone who has responded to my post for your great comments!! (I just joined yesterday and I "think" this post addresses everyone as a group...at least thats my intention.) :)

I have tried CGI.pm on a few occasions but I kept getting a syntax error right at the line where is says "use CGI.pm". I have the -w turned on at the end of the shebang line but really couldn't obtain any useful reason why it crapped.
I tried 'use CGI' same problem...
So out of frustration I went back to the cgi-lib.pl and all was well again "sort of"... The main problem I have with cgi-lib.pl is that sometimes even if the code appears to run ok (That is - I get the desired html printout back to the screen) I sometimes still get the dreaded:
"500 Internal Server Error"
"Premature end of script headers:"
error messages and thats all it says. I was able to resolve much of that when I included the &PrintHeader statement on the line before I did the "here" statement. That error really is a big pain to get rid of... Perhaps using the CGI.pm module is better at handling that or produces a more valid or reliable header.

dvergin; you are right about my indents and comments. Actually I'm not a mad commenter, I did most of those for the sake of the post and to be as descriptive as possible. But the indents DO make things MUCH clearer and cleaner. I will definitely modify my existing code. I was getting some error messages specifically near the "else" statements and that was probably a big part of it.

I will try some of the examples that were given and then give an update in a day or two, time permitting.

Again thanks to everyone for your input!! cobes... :) I study & study & study but I still... one of these days...

use strict;
my @lines = <DATA>;
chomp @lines;
foreach (@lines) {
   my @words = split " ", $_;
   print "\$_: '$_'\n";
   foreach (@words) {
      print "'$_' ";
   }
   print "\n\n";
}
__DATA__
 Delimit each  word with   one  or more spaces
   This  is  the    second  line
[download]

$_: ' Delimit each  word with   one  or more spaces'
'Delimit' 'each' 'word' 'with' 'one' 'or' 'more' 'spaces' 

$_: '   This  is  the    second  line'
'This' 'is' 'the' 'second' 'line'
[download]

   my @words = split;
[download]

--Jim

• Stop using cgi-lib.pl before you become too familiar with it. You just cause yourself that much more pain the day you migrate to using the CGI module, which can be used in a procedural manner, no need to dip your toes into OO-water if you feel you aren't ready for it. Everybody generating web pages with perl knows about CGI.pm, and you have much experience to draw upon. Hardly anyone these days knows much about cgi-lib.pl apart from the fact that it is Bad and should be avoided.
  
  
• Don't name your subs Sub1, Sub2 ... SubN. Sure, it makes it easy at a glance to count how many distinct subroutines you have written, but that kind of information is not important. How do you know at a given moment whether it's Sub23 or Sub3 that you should be calling. Give them discriptive names that describe what they do. They should do only one thing, and do it well, so it shouldn't be too hard to name them.
  
  
• Don't call subroutines like &this(). Drop the ampersands and call them like that(). This actually has an important semantic difference, one that could possibly trip you up unless you know what you are doing. Dropping the & will make this work the way you expect when subs call other subs.
  
  
• The code if (@lineDB eq =~/$item\/t/) is not legal perl. If you are looking to see whether a scalar contains the value of $item followed by a tab, then you would write

    if( $var =~ /$item\t/ )
  [download]

  On the other hand, if you want to see whether an element of an array contains the value of $item, then you have to use the grep operator to apply the test to each element in turn:

    if( grep { /$item\t/ } @arr )
  [download]

  Of course if you only want to check the first element for this possibility, then you would use the first example, with something like if( $arr[0] =~ /$item\t/ ) which I think is what you really want.
  
  
• Storing information in flat files works quite well, you don't always need a relational database.
  
  

Have fun

g r i n d e r
print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u';