[lancebeet]

Does ls really follow the unix philosophy though? GNU ls can show file permissions, modification timestamp, author, size, sort the listing etc. It does a lot more than a simple directory listing. We've just gotten used to its current extra functionality.

[bayindirh]

File permissions, inode number, dates associated with a file are all features of the files, and it's natural to be a part of a directory/file lister.

One can always create separate tools for all the extra functionality in ls, however without the file name, associating all the information would be hard, so if these properties need a file name to be meaningful, why not add it into a single tool?

It's not like ls is changing group/owner, mode, or modifying timestamps or doing filesystem dependent things. It just lists files, with a bunch of extra information, if you want.

[alerighi]

File permission, timestamps and other stuff are things that a directory listing program should show you.

Regarding sorting, one can say that you can pipe the output to sort. True, but less efficient. Most filesystem implementation already give you the directory listing sorted in alphabetical order. So ls can be aware of that cases and simply give you the sorted list as returned by the operating system, in case one of that filesystem is used, without wasting time sorting an already sorted list.

[Someone]

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.

[alerighi]

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).

[redleader55]

You can get all that info with a single stat() syscall. Looking into git for more info, is significantly more complicated.