[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 195
  • Last Modified:

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

  • 3
  • 3
  • 2
1 Solution
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?
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.  
ISGDudeAuthor Commented:
I put   sleep 5 ;
at the end of the sub and it still fails on the 2nd time thourgh.

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


sub process_file {
   my ($fileIn) = <{$dirfile}> ;  #  < returns undef on 2nd call
   my $fileout = $fileIn . "_sum" ;
   open (LOG , "<$fileIn") or die "$fileIn $!\n" ;
ISGDudeAuthor Commented:
That works.
What is it doing and why do you need it?
In scalar context, glob iterates through
               such filename expansions, returning undef when the list is
($fileIn) =
puts it in array context
      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-

       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>) {
               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

           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*>;


           $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]);
Which is why I was asking whether you should really wanted to be reading it into @fileIn rather than $fileIn...

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 3
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now