NAME

IO::Dirent - Access to dirent structs returned by readdir

SYNOPSIS

use IO::Dirent;

opendir DIR, "/usr/local/foo";
my @entries = readdirent(DIR);
closedir DIR;

print $entries[0]->{name}, "\n";
print $entries[0]->{type}, "\n";
print $entries[0]->{inode}, "\n";

DESCRIPTION

Returns a list of hashrefs. Each hashref contains the name of the directory entry, its inode for the filesystem it resides on and its type (if available). If the file type or inode are not available, it won't be there!

IO::Dirent exports the following symbols by default:

readdirent

The following tags may be exported to your namespace:

ALL

which includes readdirent and the following symbols:

DT_UNKNOWN
DT_FIFO
DT_CHR
DT_DIR
DT_BLK
DT_REG
DT_LNK
DT_SOCK
DT_WHT

These symbols can be used to test the file type returned by readdirent in the following manner:

for my $entry ( readdirent(DIR) ) {
    next unless $entry->{'type'} == DT_LNK;

    print $entry->{'name'} . " is a symbolic link.\n";
}

For platforms that do not implement file type in its dirent struct, readdirent will return a hashref with a single key/value of 'name' and the filename (effectively the same as readdir). This is subject to change, if I can implement some of the to do items below.

CAVEATS

This was written on FreeBSD which implements a robust (but somewhat non-standard) dirent struct and which includes a file type entry. I have plans to make this module more portable and useful by doing a stat on each directory entry to find the file type and inode number when the dirent.h does not implement it otherwise.

Improvements and additional ports are welcome.

TO DO

• For platforms that do not implement a dirent struct with file type, do a stat on the entry and populate the structure anyway.

• Consider making readdirent return a list of objects instead of a list of hashrefs. Nah...

• Do some memory profiling (I'm not sure if I have any leaks or not).

COPYRIGHT

Copyright 2002 Scott Wiersdorf.

This library is free software; you can redistribute it and/or modify it under the terms of the Perl Artistic License.

AUTHOR

Scott Wiersdorf, <scott@perlcode.org>

ACKNOWLEDGEMENTS

Thanks to Nick Ing-Simmons for his help on the perl-xs mailing list.

SEE ALSO

dirent(5), perlxstut, perlxs, perlguts, perlapi