Re: find -delete .. Do What I Mean?

[James Youngman]

On 9/5/07, Matthijs De Smedt <address@hidden> wrote:
> I have an issue with the way find handles its arguments. Perhaps this has
> been discussed before, but I couldn't find it.

It's in the first paragraph of the manual page:-

       This  manual page documents the GNU version of find.  GNU find searches
       the directory tree rooted at each given file  name  by  evaluating  the
       given  expression  from left to right, [...]

> Today I wanted to remove some files from a directory tree using find. I
> viewed the list of files to remove using "find -iname *-1*.jpg". Then I

That is also an error.  See the section NON-BUGS in the find manual page.


> wanted to delete them using "find -delete -iname *-1*.jpg".
>
> With all other tools I use, I'm used to indifference of the order of the
> arguments. In find's case, placing -delete before -iname happily deletes
> every file and folder below the current directory. Without warning or
> confirmation.

Yes, because - as you point out - that's what you told find to do.
My sympathies if this was accidental.

> Even if this is not a bug, this clearly does not follow the
> "Do What I Mean" principle.

True enough.  But the same would not be true for myself and others
(because they already know how find is supposed to work, and therefore
have their own expectations).

> I would like to know if this can be submitted as a bug. And if not, why this
> behavior was chosen.

This has been the way that find has worked for as long as it has
existed, as far as I know.  Certainly that seems to be the way it
worked in Version 7 Unix, in 1979.   I cannot speak to why find was
originally designed in this way.

However, the most useful way to visualise the operation of find is
that the find command line is in fact a little language (see
http://c2.com/cgi/wiki?LittleLanguage) for describing what files you
want to select, and what you want to do with them.    If you think of
it this way, it becomes easier to understand the fact that the
language has precendence rules and lazy evaluation, for example.   In
fact, in findutils version 4.3, the little language even has an
optimiser.

It's too late in the evolution of find to label this behaviour as a
bug, I think.   If it is any consolation, the V7 manual page for find
says:-

BUGS
  The syntax is painful

Would it have helped to extend the EXAMPLES section in the manual page
or to enhance the Info documentation in some way?     If you could
enumerate the bits of documentation you looked at before proceeding,
it may become obvious to us which one of those sections needs to have
a clearer warning.

Thanks,
James.