>view the Unix philosophy as a means to an end and not an end to itself

it won't be a means to an end any more if you don't preserve it, so not breaking that aspect of it has to be one of your ends. if you use it to take ls to a new place but that place is not within the ecosystem, it will be an evolutionary dead end, or worse, the first meteor in the meteor storm that ends all life.

current/traditional unix may not be the be-all/end-all, but replacing it/changing it requires viewing it comprehensively and changing all the tools at once or having a plan to. A good example of this is Plan9

I don't know what you're trying to say and I don't see how it's in conflict with anything I've said.

>not an end to itself

it is an end to itself. the reason it's a means to an end is because that was its end goal. in being a means to an end, it is an end (its end) unto itself, opposite to what you said, imho

I still can't parse what you're saying. The Unix philosophy is a means to an end, where the ultimate end is improved user experience. The means is de-coupling and composition. But there are other means to improving the user experience.

> in being a means to an end, it is an end (its end) unto itself

This either makes zero sense or is vacuously true and clearly not in conflict with what I'm saying.

I think ripgrep specifically is counted in the comment you reply to as a tool that _does_ do one thing well, and that one should use it (or grep) in combination with an ls, instead of giving ls filtering abilities.

I suppose. But I wanted to point out that ripgrep couples functionality, specifically in contradiction to the Unix philosophy. And actually, many command, including "traditional" tooling, so as well.

The point is that many pay lip service to the Unix philosophy as if it were an end. But it isn't.

> You can still chain ripgrep. I specifically designed it so that you can chain it just like you would a normal grep.

Headings on when isatty and off when piping the output put me off when I first tried ripgrep. I don't expect the tools to change their output format on me.

Luckily, you made this behavior configurable, so I'm a happy convert now.

> I don't expect the tools to change their output format on me.

You probably do! If you've ever used `ls`, then it does exactly this.

If you mean the ANSI color stuff, yes - I do expect these to disappear :)

I meant the "shape" of the output. It just doesn't follow the principle of least surprise.

edit: you probably meant the columns. I forgot about that, I haven't parsed ls(1) output in ages ;)

Yes. The columns. The point is that commands have been changing their output format, not just their colors, based on tty for ages. So the criticism you lodge against ripgrep also applies to some of the most core commands you probably use daily.

I would be quite surprised if you didn't rely on this without even knowing it. Even a simple `ls | wc -l` relies on it.

I say this because it's tiring to see folks lament about this feature in ripgrep as if it's something new that ripgrep does. It's not. It's a well established idiom among Unix command line tools.

Isn’t “don’t parse ls” like the third commandment of Unix?

You've never done `ls | wc -l`?

I've always assumed that ls doesn't change it's output when piped; I've always done ls -1|wc -l. I guess I can save on a few keystrokes now.