GRgrumblingdev·Aug 19, 2023
I guess they could have implemented some of the flags as aliases or rather bash functions to a preset chain of invocations. The merging of flags would be difficult though.
There are many flags that change the behavior of the file system calls that would be made...such as getting additional information.
To support all the formatting commands, the piped output of `ls` would need to be very verbose and structured too...like json or something.
They had to draw boundaries of functionality at some point.
So the unix idea of "one thing" was probably defined a bit more vaguely or more end-user use case related. Convenience seemed to be king.
It would have be nicer if they could have added a shell-like pipe syntax to C (and designed the code in a more modular and stream-like way).
In the `ls` [source code][1] you can see simple blocks of steps lik
Read the rest
e:
if (!file_ignored(file)) {
...
sort_files ();
print_current_files ();
clear_files ();
}
For example the `file_ignored` function in `ls` would have made a nice reusable library (with standardized configuration params) and a cli tool (with standardized flags).
Missed opportunity to unify the shell and C, but I guess SmallTalk was kicking around at that time which went a whole lot further.
It's funny that we are still very much lacking this unification...
We don't have a high-level interpreted language that can also perform well as a system's language.
New systems languages are popping up all the time, but they are more and more hardcore (looking at you Rust). They don't embrace any aspect of scriptability.
The best effort I can think of is https://www.modular.com/.
Surely though, a native TypeScript-based language is the way. It by far has the nicest syntax out of the popular scripting languages today.
We have come so close...like with Dart...but still everyone seems to be avoiding the inevitability.
[1]: https://github.com/wertarbyte/coreutils/blob/master/src/ls.c