Re: bug#29568: Bug in find, or my mistake ?

[Bernhard Voelker]

tag 29568 notabug
close 29568
thanks

On 12/04/2017 10:34 PM, f0rhum wrote:
> Hi
> find -version
> find (GNU findutils) 4.4.2

First of all, find(1) belongs to the "GNU findutils" rather than "GNU 
coreutils".
==> CCing address@hidden

> I issued this command to remove all files "*_original" from parent tree :
> /find .. iname "*_original" -delete/
> as you see I forgot the minus sign before /iname/.

outch.

> The result was all regular files were deleted, just leaving behind empty
> directories (I don't really know why dirs remained, maybe because it is
> a synchronised folder with some exclusions that prevented remote
> deletion and the local were created back).
> Is it because /iname/ and /"*_original"/ are both seen as EXPRESSIONS
> that always return true so that -delete applies to .. and content as a
> whole ?

I'm sorry for you, but actually find exactly did what you told it to do.
The tool takes all command line arguments until the first expression
as file argument:

  $ find --help | sed 4q
  Usage: find [-H] [-L] [-P] [-Olevel] [-D debugopts] [path...] [expression]

  default path is the current directory; default expression is -print
  expression may consist of: operators, options, tests, and actions:
  ...

Therefore, you passed "..", "iname", and "*_original" as path arguments.
As the two latter probably do not exist literally, you probably got these
error messages:

  find: cannot delete ‘..’: Directory not empty
  find: ‘iname’: No such file or directory
  find: ‘*_original’: No such file or directory

The -delete action is a delicate one, so I usually run find without that
action first to see what files would get deleted.

There's nothing we can do here at GNU coreutils, and I'm quite sure
the findutils folks (which I am part of, too) can't do either.

Anyway, I'm closing this as not-a-bug in the coreutils bugtracker.

Have a nice day,
Berny