[bug #67330] -exec[dir] has odd behavior when there are a lot of files

Follow-up Comment #2, bug #67330 (group findutils): Maybe I'm wrong. My explanation should mean the warnings happen even if there are only a few files. Hopefully, something who actually knows about find's implementation will be more helpful. __

[bug #67330] -exec[dir] has odd behavior when there are a lot of files

Follow-up Comment #1, bug #67330 (group findutils): Hi, I would expect this behaviour if scanning the . directory came across "a" before coming across "b". If that's the case, find would process a first, moving files to b, and then process b, finding all of the previously moved files, and try to m

[bug #62259] find(1) manpage prune example error

Follow-up Comment #7, bug #62259 (group findutils): Rather than just changing the text "Sample output" to "Sample directories", I think it's much better to include the expected output as well (as my old patch did and as the original documentation attempted to do). Showing both teh input and output

Re: Are these system crashes fixed in the latest version?

wnside, this allows to prefix them with the dash, e.g. '-(', '-)', > '-,' and '-!', > and find(1) would accept them. > > $ find '-(' -name . '-)' > . > > I'm wondering whether any serious, existing script makes use of that. > Otherwise, I'd rather like to fix this. > > Opinions? > > Have a nice day, > Berny What exactly needs to be fixed? Why is accepting a - prefix a downside? Is it just that it's undocumented/unintended behaviour? cheers, raf

Re: [bug #46791] wishlist: no option to find devices for major/minor

On Tue, Jan 07, 2025 at 08:59:26PM +1100, raf wrote: > On Mon, Jan 06, 2025 at 04:56:05PM -0500, Bernhard Voelker > wrote: > > > Update of bug #46791 (group findutils): > > > > Status:Obsolete => None > >

Re: [bug #46791] wishlist: no option to find devices for major/minor

On Mon, Jan 06, 2025 at 04:56:05PM -0500, Bernhard Voelker wrote: > Update of bug #46791 (group findutils): > > Status:Obsolete => None > Assigned to: jay => berny > Open/Closed: Closed => Open > >

[bug #46791] wishlist: no option to find devices for major/minor

Follow-up Comment #4, bug #46791 (group findutils): That debian bug report is 18 years old and didn't get much love. You could instead use my rawhide (rh) program (an alternative to find(1)). It is mentioned in the debian bug report you refer to. rh can include major/minor device numbers in its s

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

On Thu, Dec 19, 2024 at 12:21:08PM +1100, raf wrote: > On Sat, Dec 14, 2024 at 07:55:33PM +0100, Christoph Anton Mitterer > wrote: > > > Hey. > > > > On Fri, 2024-12-13 at 23:05 +0100, Bernhard Voelker wrote: > > > I never saw a practic

Re: xargs: doesn't fail on missing terminator (which may have severe consequences)

7;s find, not xargs. And my copy of the GNU xargs [(GNU findutils) 4.10.0] manual entry says otherwise: -0, --null Input items are terminated by a null character instead of by whitespace... So the "usage output" disagrees with the manual entry. It's probably the usage output that is wrong since the manual entries for find and xargs agree with each other. cheers, raf

[bug #66374] Permissions errors from unnecessary attemp to read symlink targets

Follow-up Comment #3, bug #66374 (group findutils): That makes sense. Sorry I didn't understand the point you were making. The error doesn't happen if "-xtype l" is removed from the command. So it must be the case that the "-xtype" predicate is being executed. And it seems unlikely that any optimi

[bug #66374] Permissions errors from unnecessary attemp to read symlink targets

Follow-up Comment #1, bug #66374 (group findutils): Hi. I'm fairly sure that it's not attempting to read the symlink target. But rather, the -xtype predicate is attempting to follow the symlink in order to obtain the type of the target. That's not the same thing as reading the target. The -xtype p

Re: Re: xargs mock run

On Wed, Oct 09, 2024 at 11:49:20AM +0200, oset wrote: > raf wrote: > ... | xargs echo cmd ... Good hack. Thing is, I tried > it before and it did not work. That is why I strayed the whole topic. > Now it works, so thats OK. There is a problem though: $  echo a > > a.txt; echo

Re: Re: xargs mock run

g but I think what you are trying to achieve might look something like: echo a > a.txt echo bb > b.txt echo * | xargs echo gzip -k The find -exec version would look something like: echo a > a.txt echo bb > b.txt find . -type f -exec sh -c 'echo gzip -k {}' \;

Re: xargs mock run

e, or better name for it. You can. Just replace the actual command with "sh -c 'echo ACTUAL_COMMAND'". cheers, raf

[bug #65895] Expression order matters?

Follow-up Comment #5, bug #65895 (group findutils): Sorry I didn't make myself clear enough. I wasn't suggesting that "find . -delete" stop working. I was suggesting that it become an error for -delete to be followed by one or more pure predicate options (e.g. -name) but no side-effect options (e.

[bug #65895] Expression order matters?

Follow-up Comment #3, bug #65895 (group findutils): Perhaps it's a bug to assume that users have both read the relevant documentation and understood it. Perhaps treating a command line where *-delete* is the first search criteria could/should be treated as an error (on the principle of least aston

[bug #40577] ACL support in find (new test(s) and updating -ls)

Follow-up Comment #3, bug #40577 (group findutils): FWIW, my rawhide (rh) program, which is an alternative to find, supports searching by "POSIX" or NFSv4 ACLs on Linux, FreeBSD, Solaris, Cygwin, and macOS (which has its own type of ACLs). OpenBSD and NetBSD don't support ACLs. Its -l option does

[bug #27558] [wishlist] support for posix acl match

Follow-up Comment #5, bug #27558 (group findutils): FWIW, my rawhide (rh) program, which is an alternative to find, supports searching by (never-standardized) "POSIX" ACLs on Linux, FreeBSD, Solaris (for ufs), and Cygwin, as well as NFSv4 ACLs for FreeBSD and Solaris (for zfs), as well as macOS's

Re: Reg.. find command not working as expected in Ubuntu...

On Mon, Dec 04, 2023 at 07:37:10AM +1100, raf wrote: > On Sat, Dec 02, 2023 at 03:44:19PM +, Mannem Anil kumar > wrote: > > > Dear Concern, > > As i was exploring Linux related commands, i have executed the > > following command in terminal. Where that file

Re: Reg.. find command not working as expected in Ubuntu...

exist, there will be no output (because no matching file was found), and the exit status will be zero to indicate that no errors were encountered during the search. The exit status on Linux commands indicate whether or not an error occurred. This is the case for all commands, not just find. Not finding a file is not an error. cheers, raf

Re: How to find directories that only contain a certain type of files (e.g., .txt)?

mplete. It'll report empty directories (because 0 == 0), so: find . -type d -exec sh -c \ '[ "$(find {} -mindepth 1 -maxdepth 1 -type f -name "*.txt" | wc -l)" -gt 0 ] && [ "$(find {} -mindepth 1 -maxdepth 1 -type f | wc -l)" = "$(find {} -mindepth 1 -maxdepth 1 -type f -name "*.txt" | wc -l)" ]' \; -print cheers, raf

[bug #64605] Add support for extended attributes

Follow-up Comment #1, bug #64605 (project findutils): Hi, This has come up before: #58941 (and to a lesser extent #64253). There is a patch from seven years ago and some list discussion but there are some issues with it. It looks promising but it seems that it went quiet five years ago. Have a lo

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

Follow-up Comment #3, bug #64442 (project findutils): I had a quick look at the code, and the signal handler for SIGUSR1/SIGUSR2 is always setup without regard to whether or not the -P option was used. I couldn't see why those signals would terminate xargs (but it did when I tested it on macos an

[bug #64253] Suggestion - Add support for libmagic and xattr

Follow-up Comment #7, bug #64253 (project findutils): Fair enough. I've added it to rawhide. I'm just accepting that errors become the text being matched, and document the fact. But yeah, it is wierd. Debugging search criteria could require using %w/%W to look for error messages. Maybe it was jus

[bug #64253] Suggestion - Add support for libmagic and xattr

Follow-up Comment #5, bug #64253 (project findutils): Are there going to be new corresponding -printf % format conversions? If so, what are the letters going to be (if they are single letters)? I'd like to use the same notation in my rawhide program if possible. The only good choices for me are:

[bug #64088] find should support file attribute flags (immutable, append-only, fscrypt, etc.)

Follow-up Comment #2, bug #64088 (project findutils): [comment #0 original submission:] > ioctl(fd, FS_IOC_GETFLAGS, &flags); On some other systems, it's easier. FreeBSD, OpenBSD, NetBSD, and macOS (probably all BSDs) have an st_flags field in their stat structure, and these attributes/flags

Re: [bug #64253] Suggestion - Add support for libmagic and xattr

On Thu, Jun 01, 2023 at 07:14:55PM +0200, Andreas Metzler wrote: > On 2023-06-01 raf wrote: > [...] > > but both locations are empty. /usr/share/misc/magic is > > a symlink to /usr/share/file/magic which is empty. I > > wonder how it works. > [...] > > fi

Re: [bug #64253] Suggestion - Add support for libmagic and xattr

On Wed, May 31, 2023 at 11:19:27PM +0200, Bernhard Voelker wrote: > On 5/27/23 01:39, raf wrote: > > I could be wrong, but I don't think a -mime predicate adds much value. Since > > mimetypes are determined by file name extension anyway, [...] > > I don't thi

[bug #64253] Suggestion - Add support for libmagic and xattr

Follow-up Comment #1, bug #64253 (project findutils): Hi, As far as I know, all the versions of find that have an -xattr predicate only allow searching by the name of the extended attribute (or perhaps just the fact of their existence?). I wrote a find alternative called rawhide (rh) that support

[bug #64171] find is missing folders on my mac

Follow-up Comment #3, bug #64171 (project findutils): Just a data point. I can't reproduce this (using gfind from macports and macos-10.14.6). My /opt and /Users appear in the output. I could understand some parts of /Users not appearing in recent versions of macOS unless gfind (or maybe Terminal.

[bug #64100] wish/request: please reserve -printf "%V %v %E %R %r %B %e %J %I %z %x %X %j"

Follow-up Comment #6, bug #64100 (project findutils): [comment #5 comment #5:] > Regarding format specs like "left-justified in a column of width 20": > I don't believe that it s find(1)s task to do formatting, and such features would > add unnecessarily large code while subsequent and existing fo

[bug #64100] wish/request: please reserve -printf "%V %v %E %R %r %B %e %J %I %z %x %X %j"

Follow-up Comment #4, bug #64100 (project findutils): [comment #2 comment #2:] > It might also be useful to allow the user to specify how the program should respond if a format specifier is > > (1) unknown to the implementation > (2) known to the implementation but not supported on the platform

[bug #64100] wish/request: please reserve -printf "%V %v %E %R %r %B %e %J %I %z %x %X %j"

Follow-up Comment #3, bug #64100 (project findutils): [comment #1 comment #1:] > This is quite a sizeable chunk of the available namespace. Yes, but currently unclaimed and therefore safe to claim (according to the existing documentation). > I suggest instead we agree a compatible way to exten

[bug #64100] wish/request: please reserve -printf "%V %v %E %R %r %B %e %J %I %z %x %X %j"

URL: <https://savannah.gnu.org/bugs/?64100> Summary: wish/request: please reserve -printf "%V %v %E %R %r %B %e %J %I %z %x %X %j" Group: findutils Submitter: raf Submitted: Sun 23 Apr 2023

[bug #56855] find -printf %h gives an empty string for the root directory '/'

Follow-up Comment #2, bug #56855 (project findutils): I think that it's correct that "the dirname of the path" is the empty string when the directory is the root directory. The root directory has no name. The path separator ("/") is not a name. More importantly, this behaviour cannot change becaus

[bug #58941] wishlist: Support for -xattr -xattrname

Follow-up Comment #2, bug #58941 (project findutils): [comment #0 original submission:] > It would be great if find could support searching for files based on the presence/absence of extended attributes (xattrs). Until this functionality is included in GNU find, you could use my "rawhide" program

[bug #64088] find should support file attribute flags (immutable, append-only, fscrypt, etc.)

Follow-up Comment #1, bug #64088 (project findutils): Another method (Linux only) is to use the functions in libe2p which is part of the libext2fs-dev package on Debian. I've written a find-alternative called "rawhide" that can search for these attributes (and project and version numbers) using f

Re: An interesting thing: about the naming of xargs

that it wasn't even a conscious decision. it's a better choice than "e" because at least "x" sounds like "ex", while "e" doesn't. cheers, raf

[bug #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

Follow-up Comment #11, bug #46305 (project findutils): [comment #9 comment #9:] > Oh, and the patch that tries unlink() if rmdir() failes with ENOTDIR. That patch is here: [PATCH] find: fix -L and -delete removing symlinks to directories https://lists.gnu.org/archive/html/findutils-patch

[bug #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

Follow-up Comment #10, bug #46305 (project findutils): [comment #8 comment #8:] > You bring up great points. > > I'd welcome a new, separate command-line option for a symlink-following delete, and the documentation change stating that -L is used during traversal only. The patch I submitted that

[bug #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

Follow-up Comment #7, bug #46305 (project findutils): [comment #6 comment #6:] > It looks like the right thing to do is to delete the link and the thing the link points to, if the `-L` option (follow links) is enabled. As I tried to explain earlier, I think that interpretation is incorrect and un

[no subject]

This version includes Bernard's improvements. It adds -L to make -type d work in all cases, and it uses the term "shell positional parameter" instead of "environment variable" when referring to $0 and $1 in the -exec command.

[PATCH] find: doc: Fix -prune SCM example/directories and make it more efficient

* find/find.1 - Fix -prune SCM example directories and make it more efficient * doc/find.texi - Fix -prune SCM example and make it more efficient (two ways) * NEWS - Describe the above --- NEWS | 3 +++ doc/find.texi | 27 ++- find/find.1 | 15 +-- 3

Re: [PATCH] find: doc: Fix -prune SCM example directories and make it more efficient

On Wed, Nov 23, 2022 at 07:07:14PM +1100, raf wrote: > On Tue, Nov 22, 2022 at 11:12:00PM +0100, Bernhard Voelker > wrote: > > > Hi raf, > > Hi Berny, > > > thanks for the patch. > > Besides busy day job times here, I was actually waiting for the FSF

Re: [PATCH] find: doc: Fix -prune SCM example directories and make it more efficient

On Tue, Nov 22, 2022 at 11:12:00PM +0100, Bernhard Voelker wrote: > Hi raf, Hi Berny, > thanks for the patch. > Besides busy day job times here, I was actually waiting for the FSF legal > to add your entry into the 'copyright.list' file on the GNU fencepost server. &

Re: [PATCH] find: doc: Fix -prune SCM example directories and make it more efficient

On Sat, Nov 19, 2022 at 09:48:27AM +1100, raf wrote: > Hi, > > Here's the second attempt. I've made it clear that the only "fix" > is to the example directories and output, not to the command itself. > I've restored the three-exec version of the command

[PATCH] find: doc: Fix -prune SCM example directories and make it more efficient

ht be preferable. But I did notice other lines in find.texi that were longer than 80 characters, so I assume it's OK. cheers, raf

[PATCH] find: doc: Fix -prune SCM example directories and make it more efficient

* find/find.1 - Fix -prune SCM example directories and make it more efficient * doc/find.texi - Make -prune SCM example more efficient (two ways) * NEWS - Mention the above --- NEWS | 3 +++ doc/find.texi | 25 + find/find.1 | 13 - 3 files changed,

Re: [PATCH] find: doc: Fix -prune SCM example and really make it efficient

-d "$1"/.git ] || [ -d "$1"/CVS ]' fnord {} \; -exec sh -c 'test -d "$0"/.svn || test -d "$0"/.git || test -d "$0"/CVS' {} \; -exec sh -c '[ -d "$0"/.svn ] || [ -d "$0"/.git ] || [ -d "$0"/CVS ]' {} \; I don't like including "fnord", because I feel many readers won't immediately understand why it's there, and so it should be accompanied by an explanation of why it's there, but including such an explanation is not desirable because it has nothing to do with the point of the example which is to demonstrate -prune as an efficiency measure, not to demonstrate sh -c. But I'll use whichever version you prefer. cheers, raf

Re: [PATCH] find: doc: Fix -prune SCM example and really make it efficient

On Wed, Oct 26, 2022 at 12:35:34AM +0200, Bernhard Voelker wrote: > First of all: thanks for the patch. > A concrete code change is always a good basis for discussion. :-) > > On 10/23/22 01:54, raf wrote: > > Subject: [PATCH] find: doc: Fix -prune SCM example and really make

[PATCH] find: fix -L and -delete removing symlinks to directories

find: fix -L and -delete removing symlinks to directories Fixes https://savannah.gnu.org/bugs/?46305 * NEWS (Bug Fixes): Mention the change. * doc/find.texi (-delete action): Add explanation of the issue. * find/find.1 (-delete action): Add explanation of the issue. * find/pred.c (pred_delete): D

[PATCH] find: doc: Fix -prune SCM example and really make it efficient

* find/find.1 - Fix explanation of -prune SCM example and make it efficient * doc/find.texi - Make -prune SCM example efficient --- NEWS | 5 + doc/find.texi | 6 +++--- find/find.1 | 19 ++- 3 files changed, 22 insertions(+), 8 deletions(-) diff --git a/NEWS b/NE

[bug #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

Follow-up Comment #4, bug #46305 (project findutils): Hi, I was just about to submit a bug report about this, and found this existing bug report. I think it's a shame that it has been set to WONTFIX. It's easy to fix, and fixing it would be in keeping with the principle of least astonishment. Lu

[PATCH] find: fix -L and -delete removing symlinks to directories

Fixes https://savannah.gnu.org/bugs/?46305 * NEWS (Bug Fixes): Mention the change. * doc/find.texi (-delete action): Add explanation of the issue. * find/find.1 (-delete action): Add explanation of the issue. * find/pred.c (pred_delete): Do unlink when rmdir fails (ENOTDIR). * find/testsuite/Makef

[bug #62259] find(1) manpage prune example error

Follow-up Comment #4, bug #62259 (project findutils): It looks like my "patches" didn't get included. I've just submitted a real patch for the manual entry and the texi file via git send-email. ___ Reply to this item at:

[PATCH] doc: Add missing actions from list that suppress default -print

* find/find.1 (EXPRESSION): Add missing -print0 and -fprint0 to the list of actions that suppress the default -print action. * doc/find.texi (find Expressions): Add missing -print0 and -fprint0 to the list of actions that suppress the default -print action. --- NEWS | 4 doc/find.tex

[PATCH] doc: Add missing actions from list that suppress default

Hi, find/find.1 and doc/find.texi contain a list of the actions that suppress the default -print action. But -print0 and -fprint0 are missing from the list. This patch adds them to the list in both files. cheers, raf

[bug #62259] find(1) manpage prune example error

Follow-up Comment #3, bug #62259 (project findutils): Here is a choice of two patches. The first fixes the initially reported problem (sample directories labelled as sample output and no corresponding sample output given). The second does that and also replaces the example command with one that is

[bug #62259] find(1) manpage prune example error

Follow-up Comment #2, bug #62259 (project findutils): Another (unrelated) problem with this example is that it is supposed to be "an efficient search for the projects' roots", but it's not efficient (apart from the pruning). It invokes up to three test processes for every candidate file. It only n

[bug #62259] find(1) manpage prune example error

URL: <https://savannah.gnu.org/bugs/?62259> Summary: find(1) manpage prune example error Project: findutils Submitted by: raf Submitted on: Wed 06 Apr 2022 02:57:55 PM UTC Category: documentation Se

[bug #62230] Doc/behaviour mismatch for -printf %INVALID

Follow-up Comment #2, bug #62230 (project findutils): I suppose that's an alternative, but I don't think that making it explicitly unspecified is the best way to help users. It seems like a way to allow programmers to (unconsciously) shift blame onto any users who "do the wrong thing" and then enc

[bug #62230] Doc/behaviour mismatch for -printf %INVALID

URL: <https://savannah.gnu.org/bugs/?62230> Summary: Doc/behaviour mismatch for -printf %INVALID Project: findutils Submitted by: raf Submitted on: Tue 29 Mar 2022 09:17:07 AM UTC Category: find Se