
The History of the Design of Unix’s Find Command (1995) - pmarin
http://doc.cat-v.org/unix/find-history
======
kazinator
Let's use ( ) for grouping, instead of [ ], so people have to escape them when
using find through a Bourne-like shell: \\( \\). And what better terminating
token for -exec than the semicolon!

~~~
simias
find was actually introduced several years before the bourne shell, so that's
a bit unfair. I assume that the syntax was less awkward when it was first
released.

Not that I don't agree that it's a pain to use nowadays.

------
philh
> WHAT idiot would program a command so that you have to say -print to print
> the output to the screen. What IDIOT would make a command like this and not
> have the output go to the screen by default.

You don't need to say -print. It's always printed by default for me, and the
man pages (on both linux and OS X) confirm this.

> If the expression contains no actions other than -prune, -print is performed
> on all files for which the expression is true. [linux]

> If none of -exec, -ls, -print, -print0, or -ok is specified, the given
> expression shall be effectively replaced by ( given expression ) -print. [OS
> X]

Has this only been added in the last 20 years?

~~~
KWxIUElW8Xt0tD9
I have written _many_ cross-platform shell scripts over the years. The -print
option may have been made standard by the GNU implementation and then spread
-- I don't know -- but at least on some older versions of UNIX you do indeed
need to specify -print or it won't.

~~~
vram22
Yes, I think that is true. Speaking from memory, but I've worked on Unix for
long, and I think I remember that on some older Unix versions, you had to
specify -print, otherwise it would walk the directory tree according the
conditions you specified (such as filename wildcards, the -o option (for OR),
etc.), but would produce no output for that walk.

------
triangleman
Is unix shell one of those things you just have to suffer through for 3-6
weeks before "getting it"? Kind of like learning a musical instrument?

Also would anyone recommend learning how to use Windows PowerShell and again
would that have the same kind of insane learning curve?

I'm just asking to make sure I'm not crazy and that command lines do in fact
have a very high learning curve. Every time I attempt it, I fail because I
don't know how to use these freaking flags and switches, and it's really hard
to ask the computer how to use them. And that's if you know which command to
use.

~~~
LukeShu
One major thing is that there is so much inconsistency.

Several posters here have commented on how find is a terrible tool with weird
syntax. It's not actually terrible or weird, it's just different... because it
pre-dates most everything else.

And it is hard to know how to ask the computer how to use the tools. Is the
flag you need in `cmd -h` (traditional) or `cmd -help` (X11) or `cmd --help`
(GNU) or `cmd --usage` (other GNU) or `man cmd` (UNIX; `man` is short for
"manual") or `info cmd` (GNU)?

mstade said that "On any reasonable unix" the solution is `man cmd`. That's in
general true, but apparently GNU/Linux isn't a reasonable unix then[1] (one
may even say that it's not Unix :P ). Often (mostly for GNU commands), the man
page is crappy (don't ever bother with the wget man page, `wget --help` is
what you want) or non-existent. But it's a good place to start, then you can
try working through the options I listed above... after some point you'll gain
some intuition for which are the more likely ones to yield results based on
who the publisher of the software is.

untothebreach's suggestion to bookmark the man pages for a system that has
consistently good man pages, even if they aren't 100% compatible with the
version of the command you have. He recommended OpenBSD, which is a good
choice. When I was new, I leaned pretty heavily on the FreeBSD man pages
[https://www.freebsd.org/cgi/man.cgi](https://www.freebsd.org/cgi/man.cgi) .

[1]: Plug: I actually wrote a blog post once on why documentation on GNU/Linux
sucks. [https://lukeshu.com/blog/poor-system-
documentation.html](https://lukeshu.com/blog/poor-system-documentation.html)

~~~
dmckeon
To make `info cmd` more like `man cmd` do:

    
    
        info --subnodes "$@"  | less

~~~
luckydude
Thank you for this one, that's new to me.

------
gauravagarwalr
I have found the `find` command and its API to be the hardest to learn. 3+
years on *NIX machine, spending close to 70% time on the command line when not
browsing, and yet I still am not comfortable with `find`.

~~~
gregwtmtno
I combine "find ./" and grep instead of learning how to use find. (I'm a
terrible person.)

~~~
marcosdumay
find . | grep 'abc' === find . -name 'abc' find . | grep -i 'abc' === find .
-iname 'abc'

Here, saved you a pipe :)

(Oh, and with -exec and -delete, not needing that pipe is incredibly useful.
Find is an incredibly powerful command.)

~~~
Sodel
Sorry if this is pedantic, but actually:

    
    
        find . | grep 'abc' === find . -name '*abc*'
    
        find . | grep -i 'abc' === find . -iname '*abc*'
    

The -name and -iname options do a verbatim file name check if you don't
include those wild-card asterisks. I've been inconvenienced by having to go
back and add them often enough that this is burned into my brain. :-)

------
revscat
OS X users: check out the mdfind command. It doesn't work on dot directories,
but for quickly finding files, I try it first simply because the command
syntax is so much easier for me to remember.

~~~
misiti3780
just tried it out - it caused iterm to crash

~~~
fintler
To be fair, iTerm probably caused iTerm to crash.

~~~
misiti3780
very true!

------
Random_BSD_Geek
find has a worse reputation than it deserves. Yes, its learning curve is
steep; when I was learning Unix, find was one of the commands that really
stymied me. But like many powerful tools once you've learned it you can do
some wonderful things with it.

Here's a random example: Prune a a scratch directory of files older than one
week.

find /dir -type f -mtime +7 -delete

How would you do it without find? (Serious question. I know it can be done
with other tools but since I can do it in one line with find I've never
bothered to look for another solution.)

~~~
zokier
> How would you do it without find? (Serious question. I know it can be done
> with other tools but since I can do it in one line with find I've never
> bothered to look for another solution.)

With python you can do something like

    
    
        [os.unlink(file) for file in [os.path.join(*path_parts) for l in [list(zip(repeat(root),files)) for root,dirname,files in os.walk('/tmp') if len(files) != 0] for path_parts in l] if datetime.fromtimestamp(os.stat(file).st_mtime) < datetime.now() - timedelta(days=7)]
    

...I suspect there might be bit more elegant solutions too

~~~
monochromatic
Woof. That is one python program I would _not_ call "executable pseudocode."

~~~
zokier
More idiomatic version is more readable but also more verbose:

    
    
        cutoff_date = datetime.now() - timedelta(days=7)
        for basepath,_,files in os.walk('/tmp'):
            for filename in files:
                filepath = os.path.join(basepath, filename) 
                if datetime.fromtimestamp(os.stat(filepath).st_mtime) < cutoff_date:
                    os.unlink(filepath) 
    

Python is not really that great when forced to oneliner format, and I'm not
really a good code golfer anyways.

------
336f5
This doesn't explain the history of `find`. Saying 'a specification made us do
it' is not an explanation, it is passing the buck.

------
bane
If you want to take a lesson from this, try your best to fight bad
specifications, and if you are in a position to accept or not accept code with
a bad interface, don't accept it.

Bad code lives forever and find has been a curse on *nixers ever since.

------
tragomaskhalos
"-exec ls -l {} \;"

""{} \;" ?? Whaaaa ?"

"Hush child; just type the incantation, and all will be well"

------
racl101
I love Unix shell, but I gotta admit, the find command is kind of a mind fück.

------
TerryADavis
[http://www.templeos.org/Wb/Adam/Opt/Utils/Find.html](http://www.templeos.org/Wb/Adam/Opt/Utils/Find.html)

Must handle binary graphics in source code.

