4 ms·
The official conclusion by GNU is that "ls" has already been a lost battle back in Unix's days when decisions were made to change its behavior between single-co
by segfaultbuserr 6y ago
The official conclusion by GNU is that "ls" has already been a lost battle back in Unix's days when decisions were made to change its behavior between single-column and multi-column modes according to whether the output is a terminal or not, and since then more and more features have been progressively introduced. The mere existence of "ls" actually violates the GNU Coding Standard [0].
> Please don’t make the behavior of a utility depend on the name used to invoke it [...] Instead, use a run time option or a compilation switch or both to select among the alternate behaviors [...] Likewise, please don’t make the behavior of a command-line program depend on the type of output device [...]
But,
> Compatibility requires certain programs to depend on the type of output device. It would be disastrous if ls or sh did not do so in the way all users expect. In some of these cases, we supplement the program with a preferred alternate version that does not depend on the output device type. For example, we provide a dir program much like ls except that its default output format is always multi-column format.
As a result, GNU provides a "dir" command since the early 90s, which is meant to be a consistent alternative to "ls". Yes, unlike what the myth said, it was not here to help CP/M or DOS users.
The issue of "ls" has been described in this StackExchange answer by Eliah Kagan [0],
> When its standard output is a terminal, ls lists filenames in vertically sorted columns (like ls -C). When its standard output is not a terminal (for example, a file or pipe), ls lists filenames one per line (like ls -1). When its standard output is a terminal and a filename to be listed contains control characters, ls prints ? instead of each control character (like ls -q). When its standard output is not a terminal, ls prints control characters as-is (like ls --show-control-chars).
On the other hand,
> Whether or not its standard output is a terminal, dir lists filenames in vertically sorted columns (like ls -C). Whether or not its standard output is a terminal, when dir encounters a control character or any other character that would be interpreted specially if entered into a shell, it prints backslash sequences for the characters. This includes even relatively common characters like spaces. For example, dir will list an entry called Documents backups as Documents\ backups. This is like ls -b.
[0] https://www.gnu.org/prep/standards/standards.html#User-Interfaces https://www.gnu.org/prep/standards/standards.html#User-Inter...
[1] https://askubuntu.com/questions/103913/difference-between-dir-and-ls-terminal-commands https://askubuntu.com/questions/103913/difference-between-di...
- coolgeek 6y agoYes. The more important point of the article is that behavioral changes in *nix commands/utilities have enormous downstream consequences that often get ignored or lose out to some Platonic ideal of "better" or perfection