Sorted in _some_ order that may be similar to that of the current locale, but isn’t necessarily exactly the same.
I think it is highly likely they will be somewhat different because file systems that order directory entries alphabetically (1) either
- can’t keep track of Unicode version updates (if they did, old disks could end up having entries stored out of order), so they have to guess how entries for Unicode code points assigned at some future time will sort. I don’t think that can be reliably done.
or
- have to store some data on disk to tell users what the ordering is (original Mac HFS did something like that by storing the code page to be used to interpret the byte sequences of file names as characters on disk). That would mean ls would have to get that data from disk, and only if it matches the current locale, could skip the sorting step.
There also is the risk of bugs in the implementation that can’t be fixed once millions of disks exist (the original Apple HFS file system had a bug there).
There’s also the possibility of traversing mount points during a recursive ls or even of union mounts (https://en.wikipedia.org/wiki/Union_mount) during non-recursive listings, which means the on-disk order can change during listing.
⇒ I doubt ls uses this trick (I haven’t checked any ls sources, though, so corrections welcome)
(1) that in itself is a weird idea, as, on Unix, file names are byte sequences, not character strings. That’s a different subject, though.
Of course with alphabetical I really meant in the order considering the name as a byte string (that is what every UNIX filesystem does), that is if you use characters that fit in the ASCII table is alphabetical (well, not really since capital letters come first).
I think it is highly likely they will be somewhat different because file systems that order directory entries alphabetically (1) either
- can’t keep track of Unicode version updates (if they did, old disks could end up having entries stored out of order), so they have to guess how entries for Unicode code points assigned at some future time will sort. I don’t think that can be reliably done.
or
- have to store some data on disk to tell users what the ordering is (original Mac HFS did something like that by storing the code page to be used to interpret the byte sequences of file names as characters on disk). That would mean ls would have to get that data from disk, and only if it matches the current locale, could skip the sorting step.
There also is the risk of bugs in the implementation that can’t be fixed once millions of disks exist (the original Apple HFS file system had a bug there).
There’s also the possibility of traversing mount points during a recursive ls or even of union mounts (https://en.wikipedia.org/wiki/Union_mount) during non-recursive listings, which means the on-disk order can change during listing.
⇒ I doubt ls uses this trick (I haven’t checked any ls sources, though, so corrections welcome)
(1) that in itself is a weird idea, as, on Unix, file names are byte sequences, not character strings. That’s a different subject, though.