bug#27456: 25.2; Not possible to use -prune with find-dired

[Allen Li]

On Wed, Jul 12, 2017 at 12:40 PM, Michael Heerdegen
<michael_heerdegen@web.de> wrote:
> Hi Allen,
>
>> It is not possible to effectively use the -prune action with
>> find-dired.
>
> I think I can use it successfully.
>
>> With plain find, -prune would be used like:
>>
>>     find . -name "foo*" -prune -o -name "*.el" -ls
>>
>> However, find-dired wraps everything:
>>
>>     (find-dired "." "-name \\"foo*\\" -prune -o -name \\"*.el\\" -ls")
>
> I get an error when I try to eval this.  I think the backslashes should
> not be doubled.

You're right, I copied the string from a context that required them to
be escaped twice.

>
>> results in the equivalent call:
>>
>>     find . \( -name "foo*" -prune -o -name "*.el" -ls \) -ls
>>
>> Notably, this will list files matching foo*
>
> Can't you just leave out the explicit -ls in the arguments?

Nope, find-dired adds it automatically.

Try evaluating: (find-dired "~/.emacs.d" "-name \"elpa\" -prune -o
-name \"*.el\" -ls")

This translates into: find . \( -name "elpa" -prune -o -name "*.el" -ls \) -ls

This includes the elpa directory, which is not desired (this also
prints all .el files twice due to the doubled -ls, see below).

Next try running in a shell:  find . -name "elpa" -prune -o -name "*.el" -ls

Notice how the former includes the elpa directory and the latter does not.

PS Upon closer reading, it sounds like you're suggesting to do
(find-dired "~/.emacs.d" "-name \"elpa\" -prune -o -name \"*.el\" ")

This translates into: find . \( -name "elpa" -prune -o -name "*.el" \) -ls

This still includes the elpa directory which is undesired.

>
> Also, AFAIK "-prune" is about descending into directories, not about
> file names.

Directories are files; in particular, they also have file names.
Sorry, I'm not sure what you're trying to say

PPS In a sudden flash of insight, I thought of using (find-dired
"~/.emacs.d" "-name \"elpa\" -prune -false -o -name \"*.el\"")

This works for my example use case.

Since I have found a workaround for my use case, I am okay with this
being closed now, but I feel like there may be more complex find
commands that I may want to do in the future where this either does
not work or introduces a lot more complexity, in which case I (or
someone else) will have to reopen this bug or create a new one.  I
think it would be valuable for someone experienced with find to chime
in, but I think that perhaps find-dired shouldn't always construct a
command like "find \( <args> \) -ls"

>
>
> Michael.