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

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

[Allen Li]

It is not possible to effectively use the -prune action with find-dired.

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")

results in the equivalent call:

    find . \( -name "foo*" -prune -o -name "*.el" -ls \) -ls

Notably, this will list files matching foo*

Unfortunately, I'm not sure if there are any easy remedies.  Perhaps
find-dired should refrain from appending -ls if ARGS already contains
-ls.

In GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.10)

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

[Michael Heerdegen]

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.

> 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?

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


Michael.

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.

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

[Andreas Schwab]

On Jun 22 2017, Allen Li <darkfeline@felesatra.moe> wrote:

> It is not possible to effectively use the -prune action with find-dired.
>
> With plain find, -prune would be used like:
>
>     find . -name "foo*" -prune -o -name "*.el" -ls

You can use the comma operator instead of -o, so that the left operand
is only evaluated for its side effect (of -prune).

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Michael Heerdegen]

Allen Li <vianchielfaura@gmail.com> writes:

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

Yes, that's what I meant.  Don't specify "-ls" yourself.

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

I think this is the canonical solution for your use case. "-prune"
doesn't fail, so you need to add "-false" for the directory itself to be
left out.

> 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"

I doubt that it is really a big problem in practice, but I don't close
the bug for now, not being an expert on "find" myself.


Thanks,

Michael.

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

[Allen Li]

I think we can close this.  The comma operator suggested by Andreas is
the right solution.

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

[Michael Heerdegen]

Allen Li <darkfeline@felesatra.moe> writes:

> I think we can close this.  The comma operator suggested by Andreas is
> the right solution.

Ok, fine - closing.


Michael.

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

[Phil Sainty]

The two workarounds indicated here do work nicely.

For reference, to list everything except a certain directory
(.git, in this example), you could use either of the following
option sets at the "Run find (with args):" prompt:

-type d -name .git -prune , -true
-type d -name .git -prune -false -o -true

Despite that, I think it would be useful and consistent for
`find-dired' to acquire the prefix argument behaviour of `rgrep':

> With C-u prefix, you can edit the constructed shell command line
> before it is executed.
> With two C-u prefixes, directly edit and run `grep-find-command'.

This would give some users a more familiar solution to the problem
if they are not used to the particular find options needed to work
around the problem (which was the situation I found myself in just
the other day, so the new activity on this bug was very timely :)


-Phil

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

[Michael Heerdegen]

Phil Sainty <psainty@orcon.net.nz> writes:

> Despite that, I think it would be useful and consistent for
> `find-dired' to acquire the prefix argument behaviour of `rgrep':
>
> > With C-u prefix, you can edit the constructed shell command line
> > before it is executed.
> > With two C-u prefixes, directly edit and run `grep-find-command'.
>
> This would give some users a more familiar solution to the problem
> if they are not used to the particular find options needed to work
> around the problem (which was the situation I found myself in just
> the other day, so the new activity on this bug was very timely :)

Yes, that could be useful.  Do you want to provide a patch, or can you
open a new bug report with the feature request?


Thanks,

Michael.

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

[Phil Sainty]

On 09/09/18 17:32, Michael Heerdegen wrote:
> Yes, that could be useful.  Do you want to provide a patch, or can you
> open a new bug report with the feature request?

For now I have raised this as bug#32668: 26.1; Give find-dired prefix
argument behaviour equivalent to that of rgrep

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

[Phil Sainty]

What do people think about mentioning in the `find-dired' docstring
the -true, -false, and comma operators, as being particularly useful
for structuring a find command within the constraints applied by
this function?  Maybe even including a usage example for -prune?

-Phil

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

[Drew Adams]

> For now I have raised this as bug#32668: 26.1; Give find-dired prefix
> argument behaviour equivalent to that of rgrep

FWIW, in my library `find-dired+.el', which adds to `find-dired.el',
`find-dired' acts as follows (`C-h f find-dired'):

------8<---------------
find-dired is an interactive Lisp function in ‘find-dired+.el’. 

(find-dired DIR ARGS &optional DEPTH-LIMITS EXCLUDED-PATHS)

Run ‘find’ and put its output in a buffer in Dired Mode.
Then run ‘find-dired-hook’ and ‘dired-after-readin-hook’.
The ‘find’ command run (after changing into DIR) is essentially this,
where LS-SWITCHES is ‘(car find-ls-option)’:

  find . \( ARGS \) LS-SWITCHES

Optional args:

* DEPTH-LIMITS:   Minimum and maximum depths: (MIN-DEPTH MAX-DEPTH).
* EXCLUDED-PATHS: Strings matching paths to be excluded.
                  Uses ‘find’ switch ‘-path’.

When both optional args are non-nil, the ‘find’ command run is this:

  find . -mindepth MIN-DEPTH -maxdepth MAX-DEPTH
         \( -path EXCLUDE1 -o -path EXCLUDE2 ... \)
         -prune -o \( ARGS \) LS-SWITCHES

where EXCLUDE1, EXCLUDE2... are the EXCLUDED-PATHS, but shell-quoted.
------8<---------------

The same is true for `find-name-dired' and `find-grep-dired' - they make the same use of `-prune', as does the new command `find-time-dired' (`C-h f'):

------8<---------------
find-time-dired is an interactive Lisp function in ‘find-dired+.el’.
 
(find-time-dired DIR MIN-TIME MAX-TIME &optional DEPTH-LIMITS
EXCLUDED-PATHS)

Find files in directory DIR newer or older than a timestamp.
The output is shown in a Dired buffer.

MIN-TIME is a format-time string parsable by ‘parse-time-string’, such
 as "2014-12-25 23:59:00".  Only files newer than this are shown.
 If MIN-TIME is nil or a string matching regexp "^\s-*$", there is
 no lower time limit.

MAX-TIME is also a format-time string parsable by ‘parse-time-string’.
 Only files older than this time are shown.
 If MAX-TIME is nil or a string matching regexp "^\s-*$", the upper
 time limit is the current system time.

Optional arg DEPTH-LIMITS is a list (MIN-DEPTH MAX-DEPTH) of the
 minimum and maximum depths.  If nil, search directory tree under DIR.

Optional arg EXCLUDED-PATHS is a list of strings that match paths to
 exclude from the search.  If nil, search all directories.

If args DEPTH-LIMITS and EXCLUDED-PATHS are both non-nil then the
command run is essentially the following:

    find . -mindepth MIN-DEPTH -maxdepth MAX-DEPTH
           \( -path EXCLUDE1 -o -path EXCLUDE2 ... \)
           -prune -o \( -TIME-SWITCH -SINCE-MIN -TIME-SWITCH +SINCE-MAX \)
           LS-SWITCHES

where:

* EXCLUDE1, EXCLUDE2... are the EXCLUDED-PATHS, but shell-quoted.
* TIME-SWITCH is ‘find-diredp-time-prefix’ concatenated with "min".
* SINCE-MIN is the elapsed time since MIN-TIME in minutes.
* SINCE-MAX is the elapsed time since MAX-TIME in minutes.
* LS-SWITCHES is ‘(car find-ls-option)’.
------8<---------------

This code was improved by Tino Calancha. Without having studied
the bug threads of #27456 or #32668, this sounds relevant. If it
helps I can offer this code, as a patch or as is. The code is here:

https://www.emacswiki.org/emacs/download/find-dired%2b.el