cat something|filter step 1|filter step 2|filter step 3
instead of filter step 1 something|filter step 2|filter step 3
especially when confronted with filters which need their input to be fed in different ways filter step 1 < something
filter step 1 -i something
filter something step 1
cat something|filter step 1
It may be less 'pure' to use cat as the first step in a pipe but who cares? < something filter step 1|filter step 2|filter step 3
(just pointing this out in the hope it can be of interest to someone reading the thread, I don't personally care that much about UUOC - "useless" is quite subjective, one can still reasonably find the cat version more readable).I think it's a good example of when it's worth straying from the philosophy.
Yes, it 'prints' the file to stdout which is consumed by the pipe and turned into the input for the next command in the pipeline. It doesn't matter whether you're only 'printing' a single file or a bunch of them.
As for GNU utils and the examples you mention, those indeed align with the Unix philosophy, which you clearly misunderstand.
Convenience? `tar` integrates well with compression tools, but doesn't implement compression itself. This is the epitome of the Unix philosophy. You can just as well pipe its output to any compression tool of your choice, if you prefer not using its CLI.
> why find has a DSL?
Describing an advanced CLI as a DSL is a stretch. But to humour you: flexibility, and because files have many attributes which a good finding tool should expose to the user. Whether you like its CLI or not is a separate topic, but you're mistaking minimalism for simplicity as a requirement of the Unix philosophy. Some tasks are inherently complex, and forcing a tool to be "minimal" at the expense of flexibility would be counterproductive.
Besides, you're free to choose any other tool you like more to find files on your system. The fact GNU `find` is easily replaceable is precisely a sign that it follows the Unix philosophy well. I personally use `fd` and ripgrep more often than `find` these days.
Re: `cat -v`, I hardly know the history behind it, but it doesn't really matter. As a sibling comment mentions, there are no hard rules around this topic, and people will disagree about what it really means, and how a program should be designed. If I had an opinion on the topic of `cat -v`, I would probably argue with Rob Pike about it as well. None of this means that these design principles are not worth upholding, or that we won't make mistakes along the way. But going back on topic, it's a problem when a project like systemd explicitly chooses not to follow these principles.