On 4/30/19 1:09 PM, Cristian Zoicas wrote: > The manual page of find says the following for the -prune action: > > -prune > True; if the file is a directory, do not descend into it. If -depth is > given, false; no effect. Because -delete implies -depth, you cannot > usefully use -prune and -delete together. > > So I understand that if -depth is given then -prune behaves as follows: > > a) returns false > b) it has no effect. > > The point b) is clear but I think that the documentation is not correct for > the returned value (point a)). See the example below.
Indeed, find.1 is wrong. The attached fixes it. > I would add one more more thing: the documentation of -prune would be > reformulated and explicitly specify that -prune returns true for "both files > and folders". I think with the removal of the wrong "If -depth is given, false; [...]", this is no longer needed - as for other actions like the -print family. WDYT? Have a nice day, Berny
>From fff7c38608f37bd2148500ba5b83368632535a46 Mon Sep 17 00:00:00 2001 From: Bernhard Voelker <m...@bernhard-voelker.de> Date: Sun, 5 May 2019 11:54:18 +0200 Subject: [PATCH] find.1: correct description about -prune when -depth is in effect The -prune action always returns true, also if -depth is in effect. * find/find.1 (-prune): Remove the wrong statement that -prune would return false when -depth is given. Furthermore, move the example down from -path. --- NEWS | 3 +++ find/find.1 | 29 ++++++++++++++++------------- 2 files changed, 19 insertions(+), 13 deletions(-) diff --git a/NEWS b/NEWS index 47338232..c3584a85 100644 --- a/NEWS +++ b/NEWS @@ -57,6 +57,9 @@ Both find.1 and the find texinfo manual now consistently document all of the 'N', 'L' and '?' possibilities in '-printf %Y' output when the determination of the type of a symlink target fails. +find.1 now correctly states the -prune has no effect when the -depth option is +given. Before, it wrongly stated that -prune would return false in that case. + Some minor documentation improvements are listed in "Bug Fixes" below. ** Bug Fixes diff --git a/find/find.1 b/find/find.1 index 04fbbd7d..d78993b4 100644 --- a/find/find.1 +++ b/find/find.1 @@ -760,10 +760,9 @@ The metacharacters (`*', `?', and `[]') match a `.\&' at the start of the base name (this is a change in findutils-4.2.2; see section STANDARDS CONFORMANCE below). To ignore a directory and the files under it, use -.BR \-prune ; -see an example in the -description of -.BR \-path . +.B \-prune +rather than checking every file in the tree; +see an example in the description of that action. Braces are not recognised as being special, despite the fact that some shells including Bash imbue braces with a special meaning in shell patterns. The filename matching is @@ -841,14 +840,7 @@ will print an entry for a directory called `./src/misc' (if one exists). To ignore a whole directory tree, use .B \-prune rather than -checking every file in the tree. For example, to skip the -directory `src/emacs' and all files and directories under it, and -print the names of the other files found, do something like this: -.br -.in +1i -find . \-path ./src/emacs \-prune \-o \-print -.br -.in -1i +checking every file in the tree. Note that the pattern match test applies to the whole file name, starting from one of the start points named on the command line. It would only make sense to use an absolute path name here if the @@ -1592,7 +1584,9 @@ section for information about how unusual characters in filenames are handled. .IP \-prune True; if the file is a directory, do not descend into it. If .B \-depth -is given, false; no effect. Because +is given, then +.B \-prune +has no effect. Because .B \-delete implies .BR \-depth , @@ -1601,6 +1595,15 @@ you cannot usefully use and .B \-delete together. + For example, to skip the +directory `src/emacs' and all files and directories under it, and +print the names of the other files found, do something like this: +.br +.in +1i +find . \-path ./src/emacs \-prune \-o \-print +.br +.in -1i + .IP "\-quit" Exit immediately. No child processes will be left running, but no more -- 2.21.0
