not finding <file> the 2nd time it's called

I have a list of files that needs processing.  
I created a sub routine that processes each file.
The 2nd time the sub is called, the line: my $fileIn = <$dirfile >  returns an undef.
I then get a can't find file error.

Here is a snippet of sub code I'm using

#! /usr/bin/perl
$|=1 ;  
$dirfile = "./final_erc/*.log" ;
&process_file ;
$dirfile = "./final_drc/*.log" ;
&process_file ;

sub process_file ;
   my $fileIn = <$dirfile> ;  #  < returns undef on 2nd call
   my $fileout = $dirfile . "_sum" ;
   open (LOG , "<$fileIn") or die "$!\n" ;
.
.
} # sub
 
Thanks
Randy








ISGDudeAsked:
Who is Participating?
 
ozoConnect With a Mentor Commented:

sub process_file {
   my ($fileIn) = <{$dirfile}> ;  #  < returns undef on 2nd call
   my $fileout = $fileIn . "_sum" ;
   open (LOG , "<$fileIn") or die "$fileIn $!\n" ;
}
0
 
mjcoyneCommented:
Does ./final_drc exist?  Are there any files matching *.log in this directory?  Do you chdir() anywhere in the rest of the script between the first and second call to the process_file sub?

Also, "./final_erc/*.log" would be expected to return a list of results (all the files matching *.log).  Is there a reason you're populating a scalar with this, rather than, say, an array?
0
 
ISGDudeAuthor Commented:
The files exists.  If I swap the order, the 2nd one still fails.

I do not use chdir.  The main reason is that I couldn't get the equivalent of cd .. to work and had to move on to the next problem.  

Only one log file exists in each directory.  
I  have the array checking code rem'ed out for now, until I get the basic functions to work.  
0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
ISGDudeAuthor Commented:
I put   sleep 5 ;
at the end of the sub and it still fails on the 2nd time thourgh.

0
 
ISGDudeAuthor Commented:
That works.
What is it doing and why do you need it?
0
 
ozoCommented:
In scalar context, glob iterates through
               such filename expansions, returning undef when the list is
               exhausted.
($fileIn) =
puts it in array context
0
 
ozoCommented:
      If what's within the angle brackets is neither a filehandle nor a sim-
       ple scalar variable containing a filehandle name, typeglob, or typeglob
       reference, it is interpreted as a filename pattern to be globbed, and
       either a list of filenames or the next filename in the list is
       returned, depending on context.  This distinction is determined on syn-
       tactic grounds alone.  That means "<$x>" is always a readline() from an
       indirect handle, but "<$hash{key}>" is always a glob().  That's because
       $x is a simple scalar variable, but $hash{key} is not--it's a hash ele-
       ment.

       One level of double-quote interpretation is done first, but you can't
       say "<$foo>" because that's an indirect filehandle as explained in the
       previous paragraph.  (In older versions of Perl, programmers would
       insert curly brackets to force interpretation as a filename glob:
       "<${foo}>".  These days, it's considered cleaner to call the internal
       function directly as "glob($foo)", which is probably the right way to
       have done it in the first place.)  For example:

           while (<*.c>) {
               chmod 0644, $_;
           }

       is roughly equivalent to:

           open(FOO, "echo *.c | tr -s ' \t\r\f' '\\012\\012\\012\\012'|");
           while (<FOO>) {
               chomp;
               chmod 0644, $_;
           }

       except that the globbing is actually done internally using the standard
       "File::Glob" extension.  Of course, the shortest way to do the above
       is:

           chmod 0644, <*.c>;

       A (file)glob evaluates its (embedded) argument only when it is starting
       a new list.  All values must be read before it will start over.  In
       list context, this isn't important because you automatically get them
       all anyway.  However, in scalar context the operator returns the next
       value each time it's called, or "undef" when the list has run out.  As
       with filehandle reads, an automatic "defined" is generated when the
       glob occurs in the test part of a "while", because legal glob returns
       (e.g. a file called 0) would otherwise terminate the loop.  Again,
       "undef" is returned only once.  So if you're expecting a single value
       from a glob, it is much better to say

           ($file) = <blurch*>;

       than

           $file = <blurch*>;

       because the latter will alternate between returning a filename and
       returning false.

       If you're trying to do variable interpolation, it's definitely better
       to use the glob() function, because the older notation can cause people
       to become confused with the indirect filehandle notation.

           @files = glob("$dir/*.[ch]");
           @files = glob($files[$i]);
0
 
mjcoyneCommented:
Which is why I was asking whether you should really wanted to be reading it into @fileIn rather than $fileIn...
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.