Hacker News Reader

Comment by floren | Hacker News Reader

I got used to `du | grep` after using Plan 9 a lot and still do it on Linux, but yeah really I think Plan 9 fans have had a tendency to ossify the pragmatic minimalism of the Bell Labs guys into a sort of cultishness... there's no reason we couldn't have find on Plan 9, but now it's almost a religious point not to have it.

On the other hand, the lack of find is not a particularly good rebuttal to the original point. If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched?

View on HN

> If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched?

If the poor stitching were taken as a point of pride and the community refused to fix it, then yeah, I'd assume that that community values purity over practicality. Which is exactly how I feel about Plan 9: it had good ideas and was an improvement over Unix in many ways, but it was a regression in others, in large part due to choosing minimalist aesthetics over usability.

But the fact is that you could get a decent find into Plan 9 in a day's work. Hell, you could probably just compile some existing Go version of find without any changes. Trying to get Plan 9-style namespaces into Linux is not nearly so trivial.

It's not about "find" in particular, that was just an example brought up to illustrate the general point. If "find" was the only thing missing to bring Plan9 up to Linux usability standards, that would indeed be easy to fix.

The big lesson Plan 9 seemed to have learned is that maintenance is a drag and a hinderance. find may be objectively better than du | grep for the user, but once introduced then the developers have to essentially maintain the same thing twice and carry that baggage forever into the future.

In a parallel universe where Unix did not take on so much baggage, perhaps it could have even naturally evolved towards Plan 9 and Plan 9 would have not been a necessary break. But then, like Plan 9, maybe Unix would have never rose up to see any widespread use to make that evolution significant.

Tradeoffs, as always.

I always feel guilty that find . | grep <pattern> is easier for me than remembering how find's flags work. But I think it's really a case of my brain rejecting exactly the redundant baggage you're speaking of here.

What's hard about "find . -regex <regex> -exec <stuff> /;"

Hardest thing that comes to mind is there's some slight portability differences to look out for between GNU find and BSD find that may require a quick man dive with relation to the max depth handling, but that's about it.

Ah...find's "swiss army chainsaw" mode. So, so useful. :)

You just answered your own question because it's "\;" not "/;". And the "{}" placeholder syntax isn't exactly intuitive either (maybe there is some connection to awk or sed? I only know enough of those to be dangerous).

I've used find extensively in the past two decades and even read the man page (gasp) on occasion, but it's one coreutils command that I have always found cumbersome. I recently discovered fd and I have a feeling that I will be switching to that where I can, muscle memory be damned.

> The big lesson Plan 9 seemed to have learned is that maintenance is a drag and a hinderance.

So they chose to just never finish the OS instead.

No, they did choose to finish the OS. The final release came quite a number of years ago.

The thing that I use find for most commonly is to perform a hierarchical grep, i.e

find . -exec grep -Hn regex \{\} \;

How would you do that with the du | grep combo?

... | xargs grep -Hn regex

This will also be faster, because you fork less.

Using \+ instead of \; will do the same (fork less).

du -a will need to do a stat to get the file size, which is comparatively expensive; I don't think find will (not sure)?

You're right, find won't call stat() unless it needs to. It doesn't need to for recursing through the directory tree because readdir() returns dirent.d_type these days to determine if a name is a directory.

Yes, those stat() calls can be very slow in aggregate on a large tree, especially from HDD (due to seeking) or network filesystem, if the stat information isn't already in cache.

Oh, I forgot about \+. I still pipe to xargs every single time.

Does this deal with arbitrary filenames (having newlines, control chars etc) correctly? Or does Plan9 forbid such filenames?

I've never used plan9. In Linux you do "find -print0 | xargs -0" to deal with that.

Im not sure how one can do \0 separator with du, plan9's du(1) doesn't list such option.

grep -R

but old habits die hard :)

Realistically yes. But I would still use it.

Would, but don't?

Would complain, and would use it.

Reply on news.ycombinator.com