Amongst other things, the following line is in error and will cause your script to fail:

    open(FILE, '>>fai.txt') ||  die $!;
[download]

The >> cause the file to be opened in "append" mode. You want "read" mode. You can do this to correct this:

    sub search {
        my ($file,$part_number,$revision) = @_;
        open FILE "< $file" or die "Cannot open ($file) for reading: $
+!";

        local $_;
        while (<FILE>) {
            # search line for $part_number
[download]

Note that I have have made some changes. First, I have explicitly passed the necessary arguments to the subroutine. This makes it easier to reuse or move to a library, if necessary. Further, I've localized $_. This restricts changes to $_ to the current scope, thus ensuring that if another part of your program uses $_, you won't accidentally have a strange value in there. See perldoc -f local for more information on this.

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

I see the error for the append option, but your post confused me. If I use your code as you typed it, where does it know to open the fai.txt file? Will the rest of the while block stay the same? Thanks again,
Kerry credo quia absurdum

Yes, that is exactly what you did. You declared @fields inside of search, and that is the only place it is known, because "my" creates a scoped variable. It goes out of scope outside the subroutine.

That wouldn't have been a problem if you only used @fields inside search, which I think you meant to do. But because you accidently doubled the "}" right after the end of the while loop, you ended the subroutine definition right there. You need to move that "}" to the end of the program, and then the use of @fields will still be in scope for the print statement.

P.S.: Other than the "<" fix, the other suggestions by Ovid are more a matter of good programming style than they are fixes to make your program work correctly. Ovid is suggesting that you pass in the file name as a parameter, like this:

&search("fai.txt", $PartNumber, $Revision);
[download]

#!/usr/bin/perl -w

use strict;
use Data::Dumper;



print "Enter the part you which to search for: ";
my $part = <STDIN>;
chomp($part);

my $searchresult = &search(part => $part);

if (defined $searchresult) {
    print "Located part No. $part: $$searchresult[1]\n";
} else {
    print "Your part ($part) could not be found...\n";
}
# This routine will accept a part number as an anonymous
# hash, and seach thru' a text file returning the entire
# record (pipe delimited) of the 1st occurrence
sub search {
    my %args = @_;
    my $retval;

    local*FH;
    open (FH, './parts.txt') || die "Cannot open file: ($!)";
    my @parts = <FH>;
    foreach my $line (@parts) {
        my @fields = split(/\|/, $line);
        if ($args{part} eq $fields[0]) {
            $retval = \@fields;
            last;
        }
    } 
    close FH;
    return $retval;
}
[download]

There are a number of problems with this kind of design (including, but not limited to:)

1. Enforcement of primary key integrity (there is none)
2. Locking of the file during updates
3. Scalability of the file

Putting this kind of information in a database is quite useful as the data can but cut up in any particular way, normalised (part number, description, who ordered the part), the data can be backed up using standard database backup methods, it can be rolledback (if your DB engine supports it) etc etc etc.

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

sub get_part_num {
  my $part;
  while (!$part || $part =~ /[^0-9]/) {
    print "Part Number? ";
    chomp( $part = <STDIN> );
  }
  return $part;
}

sub search {
  my ($file, $part) = @_;
  open my $db, "<$file" or die "Could not read file: $!";
  while (<$db>) {
    chomp;
    my @fields = split(/\|/, $_);
    print "Part $part found: \n\t",
      join("\n\t", @fields[1..$#fields]), "\n"
        if $fields[0] eq $part;
  }
}

search( 'fai.txt', get_part_num() );
[download]

What happens if you want part number 0 ?

-- Hofmator

I didn't really consider this option as I suppose I would never assign a product to ID 0. Zero isn't really a number, therefore why would I assign a product to a not-really-a-number ID? :P

Anyway, if you really did need part 0, then just change while (!$part || $part =~ /[^0-9]/) { to while (!defined $part || $part =~ /[^0-9]/) {. The only thing this will also change is if the user hits enter without entering anything, the program will exit. That's fine by my standards

sub find_matching_part_entry
{
  my( $filename, $part, $rev ) = @_;
  open F, "< $filename" or die "Error reading $filename: $!\n";

  my @match;

  while (<F>)
  {
    chomp;
    my @fields = split /\|/;
    if ( $fields[0] eq $part && $fields[1] eq $rev )
    {
      @match = @fields;
    }
  }

  close F;

  return @match;
}

my @matching_entry = find_matching_part_entry( "fai.txt", $part, $rev 
+);
if ( @matching_entry )
{
  print "Found part:\n";
  for ( @matching_entry )
  {
    print "$_\n";
  }
}
else
{
  print "No part matching $part, rev $rev found!\n";
}
[download]

jdporter
The 6th Rule of Perl Club is -- There is no Rule #6.