The first is that Perl runs on more than 30 OSs. For perl to guarantee an order, it would have to sort the file names before returining them to me. How annoyed would I be if I opened a directory with 15,000 files in it and perl paused for 5 seconds while it sorted the list. And how should it sort it? I would be doubly annoyed if it sorted it by name and I wanted it by date.

The second reason calls on laziness: the perl programmers aren't going to waste any precious braintime programming a directory read function if there is another one available. And there is one supplied by the OS in Unix, it's a system function called readdir(). The way to get a system directory handle is with opendir(). There's a pattern here... the perl programmers just pass the call straight through to the OS. Reading the manual for Solaris, I see that it goes out of it's way to avoid mentioning sort order for files in a directory. The reason for this is that you could have over five different types of file system, each returning file lists in a different order(by date, by size, by last accessed, by weird b-tree sort, etc.). How pissed off would we be if Solaris paused for five seconds every time we opened a directory with 15,000 files in it?

Substitute Linux for Solaris above and you have the same story, except you could have maybe 20 filesystems returning files in different orders.

____________________
Jeremy
I didn't believe in evil until I dated it.

Thanks for your help everyone. I guess it might well be creation/modification order, yes, but the main point is that we don't know for sure and can't rely on it being consistent: the OS will return whatever it feels like.

Am I right, by the way, in thinking that the <=> operator will sort by leading numerals if it finds any?
--


($_='jjjuuusssttt annootthheer
     pppeeerrrlll haaaccckkeer')=~y/a-z//s;print;
[download]

Looks like it

____________________
Jeremy
I didn't believe in evil until I dated it.

It's still probably better to use 'cmp' since you're doing a string comparison. Right tool for the right job sort of thing. In Perl, taking things on faith can come back and bite you in the ass when you least expect it.

Nothing out of the ordinary was going on. You get them in the order they were added to that directory. I'm very sure that maverick is wrong here, as well.

On Unix-ish filesystems, a file is a nameless entity identified by its inode number. A directory is a file that maps filenames to inode numbers. Because you can map many filenames to the same inode, in the same or across different directories, and because inodes of deleted files are recycled, the inode number, creation order and directory order of files have no relation to one another.

Makeshifts last the longest.

Update:Nope, that isn't right. It does have something to do with the inode and how the files are stored on disk, but I can't seem to recall what.

/\/\averick
OmG! They killed tilly! You *bleep*!!

Its the directory order by which they are returned - While this order can change depending upon file systems, this directory order generally relates to the creation order of the file entries in the directory table. The exception to this is where a directory entry is deleted - In this scenario, the directory entry is recycled and any subsequent files stored will preferentially replace the previous directory entry, thus the storage order is no longer wholly 'by creation time'.

 

Some fairly good points were made on this topic the last time I saw it raised (Is readdir ever deterministic?)--not so exactly the same question you just asked, but some similar and closely related answers.