In #Unix Programmer's Manual (1979), the `find` manual entry has a BUGS section listing "The syntax is painful." as a bug.

@avidseeker I assume dd and find were designed by two Bell Labs employees trolling each other.

dd isn't really bad I guess. Just weird. find seems like it should be more normal, but is perpetually frustrating.

@avidseeker Yes. Yes, it is.

As an alternative to find(1), a lesser-known command called locate(1) was introduced in BSD Unix in the mid-80s. It uses a prebuilt, compressed database of pathnames to locate files by name.

I got familiar with it on a network of Apollo Domain/IX workstations. I set up cron jobs to run nightly searches on each host's filesystem and merge the results into a database of all the files on the LAN. That wasn't in the man page.

https://archive.org/details/login-feb83/page/n7/mode/2up?view=theater

;login: February 1983 : USENIX Association : Free Download, Borrow, and Streaming : Internet Archive

;login: The USENIX Association NewsletterVolume 8, Number 1, February, 1983

Internet Archive
@avidseeker I also became fascinated with its use of bigrams, and I later used a bigram-frequency technique (which I learned, much later, is called "Dice's coefficient") as a fuzzy string match library, which I still carry with me from one language to another.
@submicron @avidseeker
I still have a cron job update a list of files for a few filesystems once a week, for a command that searches them. It hadn't occurred to me that I do that because I started with BSD in the 80s, but it makes sense...

@submicron @avidseeker The standard `locate(1)` program in Linux distros for a long time was `mlocate`, which had some performance problems as we reached more modern volume sizes and inode-tastic tree formats such as git repositories.

Fortunately `plocate` improves the performance back to the point where it's almost free to just try running `locate(1)` first and grepping out the paths you want.

https://plocate.sesse.net/

plocate, a much faster locate

plocate, a much faster locate.

@avidseeker The syntax is still the same. Checks calendar, 44 years later!
@avidseeker checks out. find(1) was one of the utilities i took a while to actually learn to use properly, i thought it was something like `find filename` and then it'd just recursively search, but now i have the usual unix stockholm syndrome with it and use it a lot
@avidseeker The word "painful" disappeared from the BUGS section some time between AT&T Unix 5 and AT&T Unix 8 (and BSD 2 and BSD 4 respectively) following major changes and one complete rewrite of the command, the pain however remains to this day.

@avidseeker @alanc I miss a lot of the old jokes in “BUGS” man page sections. Looks like the FreeBSD tunefs(8) still has this one from 4.2bsd though:

“You can tune a file system, but you cannot tune a fish.”

https://man.freebsd.org/cgi/man.cgi?tunefs(8)

FreeBSD Manual Pages

@stuartmarks the Solaris tunefs man page lost that line when merging with AT&T's SVR4 man pages, but @jbeck restored it in the #OracleSolaris 11.4 man pages:
https://docs.oracle.com/cd/E88353_01/html/E72487/tunefs-8.html
tunefs - man pages section 8: System Administration Commands

tunefs - tune an existing UFS file system tunefs is designed to change the dynamic parameters of a file system that affect the layout policies. When using tunefs...

@alanc @jbeck Cool! Now let me know when /usr/games is restored. 🤪
@stuartmarks @jbeck I could not imagine a worse job in 2023 than deciding which /usr/games/fortune entries to include in a globally-distributed enterprise OS release.

@alanc @jbeck Oooh, tough job. Also: I had forgotten about the division of entries into “obscene” and “scene”!

https://github.com/dspinellis/unix-history-repo/tree/BSD-4_2/usr/src/games/fortune

unix-history-repo/usr/src/games/fortune at BSD-4_2 · dspinellis/unix-history-repo

Continuous Unix commit history from 1970 until today - dspinellis/unix-history-repo

GitHub
@avidseeker to be fair, this doesn’t look very much like the modern find.

@avidseeker man etherfind man page once used to have

BUGS

The syntax of this command resembles that of find

that's an interesting syntax. i would have used a for loop in bash
@avidseeker
Extremely reproducible too.
@avidseeker can't believe they still haven't fixed this bug
@avidseeker this makes me feel so valid for the way i feel about find
@chrisisgr8 @avidseeker oh thank Xenia I thought it was just me
@avidseeker Try finding a file via a desktop GUI on any OS these days, "find" sucks less, IMHO.
@avidseeker evergreen 'find -atime +7' example that still saves disks from filling up 40 years later.

@avidseeker bestie, that's not the UPM (if only because it pre-dates troff), and the UPM isn't dated 1979; see actual UPM screenshot of find (I) in jpeg 1

I see this sentence attested /only/ in V7 (with a file date of 1979-01-10 21:16, so that'd match; see jpeg 2). but unless you have access to a scan the TUHS doesn't (and considering it's pixel-perfect, and so would the OCR need to be for your selection, you don't), the supposed screenshot is of a groff-print-from-source, which is, again, misleading at best