in reply to readdir missing one file

Your first call to readdir goes into "my $dir" and then gets discarded by the next call in the condition of the while loop. 

opendir my $Tdir, "/path/to/anywhere"
    or die "Can't opendir '/path/to/anywhere': $!";
my $dir;
while($dir = readdir($Tdir)){
    print "$dir\n";
}
closedir $Tdir;

[download]

Replies are listed 'Best First'.
Re^2: readdir missing one file
by true (Pilgrim) on Oct 17, 2008 at 16:00 UTC
    hmm, i've been using this with no errors for almost a decade. Odd that it never was a problem before. but your are right. This code works: 
    opendir Tdir, "/var/www/campbell/campbell.edu/www/content/2/";
while(my $d = readdir(Tdir)){
print "<li>$d\n";
}close Tdir;

    [download]
    jtrue
[reply]
[d/l]
      It was a problem before! That's why you never saw the '.' directory; you discarded it. Obviously, in the past you got the files from readdir ordered, with the '.' and '..' directories in front and that's not the case on RH (and shouldn't be depended on).

      Paul

[reply]
        Exactly! Reading a file or directory alters the system by incrementing pointers: it's best to read only once, but if you read more than once, at least limit your reads to once place. This sort of thing is exactly why I started reading like this: 
        my $path = "/path/to/whatever";
opendir (DIR, $path) or die "Can't read $path: $!";
my @files = grep { not /^\.{1,2}$/ } readdir (DIR);
closedir (DIR);

print join("\n", sort @files), "\n";

        [download]
[reply]
[d/l]
      Sounds like your new version of redhat has a subtle change to the readdir(2) operation (or maybe you changed the filesystem type you were on??). I am pretty sure that, in general, readdir simply returns the entries in the order that they appear in the file. You never used to see "." because it should always be the first entry in the directory file, and your script was discarding it. Now, for some reason, the first entry returned by readdir was not ".", but a file you cared about. Since opendir/readdir say nothing about entry ordering, "it's not a bug -- it's a feature":)
[reply]

        Indeed I had never relied on that behaviour myself, but on quite about every filesystem I had seen thus far would readdir return qw/. ../ as the first two entries, and yet I had never ever seen this described as a requirement, so I had always wondered if by any chance it were - except undocumented or documented in some arcane place: now we have at least one bit of experimental evidence it actually isn't. (Of course I'm not claiming to be a fs expert or let alone knowledgeable person, in which case I would have known better to start with...)

        --
        If you can't understand the incipit, then please check the IPB Campaign.
[reply]
[d/l]
[select]
      You still have two bugs and two instances of poor programming.

      • close doesn't work on directory handles. You need closedir .

      • You'll stop iterating prematurely if you have a file named 0 (zero). You need to check if the result of readdir is defined. Check if it's false isn't good enough.

      • Why are you using a global variable for the directory handle?

      • It's so easy to check opendir for errors, it's a very likely candidate for errors. Add a check! 

      my $Tdir_qfn = "/var/www/campbell/campbell.edu/www/content/2/";
opendir(my $Tdir_dh, $Tdir_qfn)
   or die("Can't read dir \"$Tdir_qfn\": $!\n");

while (defined( my $f = readdir($Tdir_dh) )) {
   print "<li>$f\n";
}

closedir($Tdir_dh);

      [download]
[reply]
[d/l]
[select]
        You'll stop iterating prematurely if you have a file named 0 (zero).
        That hasn't been true for a very long time: 
        perl -MO=Deparse -e 'while ($f = readdir $h) {1;}'
while (defined($f = readdir $h)) {
    '???';
}
-e syntax OK

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom