in reply to Re: Using File::DosGlob::glob in loop only works first time
in thread Using File::DosGlob::glob in loop only works first time

That said, I'm not sure why you're using glob at all if you only look at the first element. Why not just do unless ( -f $template_file )?

I have a list of files that I want to ensure are actually files (the user will be feeding in filenames via a configuration file and I don't want the program to go further if said file(s) don't exist). I'm using glob in case the absolute path names contain a space character somewhere.

The thing that's bothering me about this is "Why does glob give me a valid answer for the first item in my list, even when I'm using it in scalar context, and not the second?" Is it set in stone somehow, like m/$abc/o is set to only optimize the first interpretation you ask of it? Because in my example, when I use a different instance of glob (i.e. the second foreach loop/block) against the "second" filename, it kicks it out just fine (and then fails on the "previously okay" first value). In DWIM-land, I'd think that each invocation of glob, even within a foreach loop, would be independent of the last.

Though as I said before, I can move ahead with answers that work, and the slice/[0] suggestion works. :-)

Replies are listed 'Best First'.
Re^3: Using File::DosGlob::glob in loop only works first time
by ikegami (Patriarch) on Feb 24, 2006 at 21:46 UTC
    I'm using glob in case the absolute path names contain a space character somewhere.

    How does glob help you with path names that have spaces? glob accepts a file spec (i.e. something with *) and returns all matching files. It's used to allow the user to specify multiple files at once. However, since you're only interested in one file, it makes no sense to accept file specs or to use glob.

    -f works with spaces, whether you've passed the value through glob or not.

    The thing that's bothering me about this is "Why does glob give me a valid answer for the first item in my list, even when I'm using it in scalar context, and not the second?"

    When glob is called in a scalar context, it still returns all the values it would in a list context. It just returns one by one. Somehow, it has to tell you when it's done returning all the values. It does that by returning undef.

    The first time you call glob, it returns the first filename that matches the file spec.

    The second time you call glob, it returns undef since there are are no files that match the file spec passed to the first call to glob.

[reply]
[d/l]
[select]
      As anticipated above by japhy, there is an evil windows reason at work. I was getting error messages like:

      File check, cannot access C:/Program\ Files/DirDictate/soap_form/soap_
+final.dot,
No such file or directory

      [download]
      I tried preprocessing my $template_file variable with:

      $template_file =~ s#/#\\\\#g;

      [download]
      but that didn't help and so scanning around the ActiveState archives I found:

      perl-win32-users Re: using glob with filenames with spaces 
by Edward G. Orton, Jan 31 2002 7:08AM

my @html_files = glob qq{"$input_dir/*.html"};

ego
Edward G. Orton, GWN Consultants Inc.
Phone: 613-764-3186, Fax: 613-764-1721

      [download]
      Now in this case, the glob is being processed in list context, but I didn't think of "context" when I twisted this example for my needs. The file names that I wanted to test would be several absolute path names that wouldn't all have the same directory portion. So, faced with a series of files to check for filedom, I thought that having glob take its crack at creating/passing along the filename would get me its special powers of handling pathnames that include spaces in a Windows world.

      It appears that glob is acting like an iterator in which the original call to glob hangs around and gets fired with each visit to the glob line rather than new calls to glob being fired when the line repeats with the loop. I thought that perhaps wrapping an eval around my glob line would do what I wanted, but I'm rather clumsy with that command and the slice/[0] approach works quite nicely. :-)

[reply]
[d/l]
[select]
        The error is the "\" in front of the space in "C:/Program\ Files/". It shouldn't be there.
[reply]

In Section Seekers of Perl Wisdom