Hello thejasviv, and welcome to the Monastery!

Try this:

opendir(my $dirh, "/somewhere") or die;

while (1)
{
    print "$_\n" while readdir($dirh);
    sleep(1);
    rewinddir $dirh;
}
[download]

See rewinddir. I can’t test this as I’m on Windows (on which, see perlport).

Hope that helps,

thejasviv:

If you're on a Linux box, I'd suggest looking at Linux::Inotify2 to detect changes in a directory.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

I'm not a Linux person, but was just thinking that even Windows has events to notify listeners about file system changes - Glad to see that Linux also does this

SimonPratt:

Yeah, I figured people may not be aware that Linux and MacOSX also have filesystem events available. I try to use filesystem events when I can, to avoid repeated directory scanning. Especially when many directories would need scanning.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

You will have to "work around". Even if readdir would work the way you think, there'd be no guarantee that new entries would be put "at the end".

And anyway, you haven't specified what you want to do about modified files.

Actually this (non-)behavior is consistent with most other iterators on Perl.

For instance modifying a foreach @array is discouraged and modifying a %hash would reset each . A normal filehandle is controlled by tell and seek (IIRC).

So the default is to consider the iterated data as immutable.

There is no generally accepted way to handle other case except leaving it to the programmer to work around it with extra constructs.

Besides how should "a new file" be defined? Another name? Another inode? Other content? Changed timestamp?

YMMV!

#!/usr/bin/perl
use strict;
use warnings;

while (opendir my $dirh, "/somewhere/else")
{
    while (my $file = readdir $dirh)
    {
        print "$file\n";
    }
    sleep 1;
}
[download]

Thank you all for the responses. Yep, I had guessed something similar about the placement/order of new entries in the directory file, but still wanted a confirmation. Work-around like close-and-reopen, rewinddir(), etc... work well. And for those of you who wanted to know what the "new" files meant, and what I did with those, here it is: I consolidate the files written to a common network location by multiple processes running on various servers. So in each iteration, I check if any new files (files with different names than the ones I have encountered so far) have been created in the directory. If yes, I open read handlers to those files and push them onto a hash. I then iterate through all the file handlers, read any new lines, and write them all to the output file.

“Directories,” and file-systems in general, are unpredictable data structures.   Entries will not appear in any particular order.   Therefore, you must read the entire directory contents list into memory, then sort that list yourself, then work with the sorted list.   If you need to know what has appeared or disappeared, you must likewise do the comparison yourself.

Also, when you are scanning a directory, you should initiate the scan, run it fully to completion, then close it.   Don’t fall asleep with a scan left-open.   The resource that you are using might be limited, and so your process might be exerting an unforseen negative influence on its neighbors.   (And, in the most benign of circumstances, you can easily fail to see files or see files more than once.)

Note that some file metadata, such as most-recent-access timestamps, are not always supported.   They require a large number of disk writes to take place, and for a reason that might be judged to be not worth the effort (or, in the case of a truly read-only filesystem, not possible).   So, they might have been turned-off by the system administrators.

Most operating systems provide a separate API by which you can “watch” a directory to detect what changes have recently been made to it, but these facilities are specific both to the OS-type and to a particular networked file-system.   They might be privileged.   They might be “convenient, but expensive.”