4 ms·

Except that means tools aren't doing "one thing" as in the Unix philosophy. Or least I know of very few unix tools that actually do that. At a minimum they need

Except that means tools aren't doing "one thing" as in the Unix philosophy. Or least I know of very few unix tools that actually do that. At a minimum they need to bundle an argument parser (or more often reinvent their own). They also need to do the same for generating output, often in multiple different display formats depending on the precise flags used. And I think your overstating the contract argument. If `ls` changed its output format in any way (unless behind a flag) it'd break a heck of a lot of bash scripts. With a well structured output format it's better able to maintain backwards compatibility while adding new features.

follower 3y ago
> If `ls` changed its output format in any way (unless behind a flag) it'd break a heck of a lot of bash scripts. The `jc` ("CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON") documentation[1] & parser[2] for `ls` also demonstrate that reliable & cross-platform parsing of even the current output can be non-trivial based on filenames encountered, flags used & host platform--which means there's probably a non-zero number of bash scripts that are already broken but they don't know it. [1] https://kellyjonbrazil.github.io/jc/docs/parsers/ls https://kellyjonbrazil.github.io/jc/docs/parsers/ls [2] https://github.com/kellyjonbrazil/jc/blob/4cd721be8595db52b620cc26cd455d95bf56b85b/jc/parsers/ls.py#L187 https://github.com/kellyjonbrazil/jc/blob/4cd721be8595db52b6...