No, ls(1) is flexible because the philosophy is to do one thing and do it well.
ls(1) lists information about files. That's what `man ls` says it will do, and whichever flags you pass, that's what it's going to do. Providing a lot of control over how exactly it does that is (imho) doing it well.
Do you mean that in order to truly do well its one thing (list information about files), that ls had to incorporate things like these?
-o List in long format, but omit the group id.
-T When used with the -l (lowercase letter ``ell'') option, display complete
time information for the file, including month, day, hour, minute, second,
and year.
-x The same as -C, except that the multi-column output is produced with entries
sorted across, rather than down, the columns.
Or this bunch:
-p Write a slash (`/') after each filename if that file is a directory.
-r Reverse the order of the sort to get reverse lexicographical order or the oldest entries first (or largest files last, if combined with sort by size
-S Sort files by size
* -S (and -r) are redundant with `sort` (ls -lSr -> ls -l | sort -k5; ls -lS -> ls -l | sort -rk5)
-r is also very useful (I use -tr all the time, which I can't immediately see how I'd replace with sort), and while I could replace ls -lS with piping into sort, you seem to be assuming ls will always be outputting one file per line, which is far from its most useful output mode when running it in a terminal.
No, I am assuming a "do one thing" `ls` would be used in long format (or as inode numbers) whenever it need to be worked with, and would be massaged into form by further commands. For `t`, `r`, `S` and a bunch of others you'd ls, sort and then cut/awk/whatever to format into a "short form".
Not that it matters a bit.
Also, I didn't claim these weren't useful, I claimed they were redundant. Which they are.
The long (-l) format already provides the month, day, hour and minutes. -T adds only seconds and the year. No utility can possibly provide every format option that someone might find useful. If you really needed that format, and ls were leaner, you would need to write a script (in whatever language).
> And -x is a personal preference.
Basic utilities shouldn't include so many options that are variants for personal preferences.
> None of those seem especially useless.
I don't think that they are outrageously useless, but let's set the bar higher. The core utilities should be, in my opinion, much much leaner than they are.
I agree that a certain flexibility is useful in the Unix tools, but a well-founded argument can be made that flexibility costs you simplicity.
This is not to criticize ls though - I would imagine that no matter how small the operation (well aside of operations executed directly by the cpu), there's still the possibility to break it up into smaller parts.
At some point convenience just trumps modularity.
ls -lt is just more convenient than a (hypotetical) ls -t | sort | xargs fileinfo | display-fileinfo
On a related note: Windows PowerShell comes closer to this ideal by being able to send arbitrary objects between pipes. This still has the side-effect though that single commands become much more awkward to use as they don't produce output that's usable on its own.
I would imagine that no matter how small the operation
(well aside of operations executed directly by the cpu),
there's still the possibility to break it up into smaller
parts.
How? sh sucks for anything involved, but I can't think of a way to simplify pipelines much.
A pair of shell variables honored by commands that let you specify output wrappers or separators would have been nice too. Think "-Q" in gnu ls, but universally supported and user-controlled.
How do you sort a multi-column output by 3rd column?. You have to write some scripts for that.
What sort option puts 1.0K, 1.0M, and 1.0G in the right order?
Someone pointed out that ls is really doing three things - listing files, sorting them and displaying them. That seems fairly accurate, and indeed it's convenient that it does.
But it's not 'doing one thing'. I'm not saying that's necessarily bad (as I just said, it's convenient), but it's not hardline Unix-way purity.
For practical reasons like those you raise, it makes sense for ls to handle its own sorting rather than leave it to the sort command, just as it handles its own formatting rather than let the user manage it. But those features _are_ something other than just reporting file listings, whatever the motivation for the feature creep. This convenient flexibility makes ls less single-task, less Unix-adherent but more generally useful on its own.
Both of which wouldn't be the job of a "do one thing and do it well" `ls`. That one would display dates as a UNIX timestamp and sizes as bytes. Aside from that, surely if ls can format information it's possible to reverse that formatting.
Here's another thought I had about the old school unix way. Old school unix didn't have symlinks. The purpose of the filesystem is to store files, right? If you want aliases, then you should keep them in a file like /etc/symlinks. Or ~/.symlinks, then every user can have their own aliases. That's the real unix way, right? Let's not take the minimalism to absurd extremes.
It is not like 'ls' is predicting weather and telling the fortune.
It lists files and directories. It has a zillion options to control its behaviour and output. I see nothing wrong with those options if they will be of use to somebody. I use 4-5 options myself and know them by heart.
I do admit that a new user can get overwhelmed if he looks at the man page.
New users don't need to be overwhelmed by the man page. -a and -l should be enough for >99% of use cases.
ls shows up in shell scripts too, but that's almost always a mistake -- or a dependency on one of the harder-to-duplicate formatting options.