[bug #42501] Add -E option for FreeBSD/Mac OSX compatibility

Follow-up Comment #9, bug #42501 (group findutils): I realise I didn't really answer the question of which *release* -E came in in those. For FreeBSD and NetBSD, that would be their respective 5.0 version even if they're many years apart. For MacOS/X I don't know exactly, but https://github.com/

[bug #42501] Add -E option for FreeBSD/Mac OSX compatibility

Follow-up Comment #8, bug #42501 (group findutils): Oh sorry missed one: and then NetBSD added -E in: commit c43efbc1770febb15e4e1cac194fc14195dc3bba Author: daniel Date: Thu Jul 19 07:49:30 2007 + Add the '-E' option to interpret regexes as extended regexes. While we are here, fi

[bug #42501] Add -E option for FreeBSD/Mac OSX compatibility

Follow-up Comment #7, bug #42501 (group findutils): Chronologically: -regex added first to NetBSD (inspired from GNU's) in: commit 5ddc160e898d16e1f981c5f3f7c8aa41db732ac4 Author: cgd Date: Tue Jul 20 01:28:41 1999 + add -regex and -iregex primaries which, like GNU find's primaries o

[bug #61304] Contradiction about default type of regular expressions

Follow-up Comment #1, bug #61304 (project findutils): That's a duplicate of bug #52592 See also bug #58384 ___ Reply to this item at: ___ Message se

[bug #62043] The xargs -r, --no-run-if-empty Option Is Ignored When a Delimiter Is Passed

Follow-up Comment #6, bug #62043 (project findutils): [comment #4 comment #4:] [...] > OTOH I am trying to fix the documentation of xargs' inconsistent behavior, imho these two commands should produce identical output both for consistency reasons and according to the documentation but do not: > pr

[bug #59988] Documentation for the find command omits -printf %{A, T, C}z

Follow-up Comment #1, bug #59988 (project findutils): The doc says (emphasis mine): > 3.2.3 Time Formats > > Below is an *incomplete* list of formats for the directives '%A', '%C', > and '%T', which print the file's timestamps. *Please refer to the* > *documentation of 'strftime' for the full l

[bug #62043] The xargs -r, --no-run-if-empty Option Is Ignored When a Delimiter Is Passed

Follow-up Comment #3, bug #62043 (project findutils): The point is that with -d '\n' an input that contains one newline character has one empty record, and one with two newlines has 2 empty records and so on. With -0, an input with one newline character optionally followed by a NUL has one record

[bug #62089] find -size -1024k different from -size -1M

Follow-up Comment #3, bug #62089 (project findutils): That's an extension on the standard POSIX behaviour. c is the only suffix supported by POSIX find -size. Without suffix, the unit is 512 byte blocks (formerly commonly known as sectors). -size n: matches on files whose size rounded up to the n

[bug #60383] [feature-request] let find read files from stdin or file.

Follow-up Comment #18, bug #60383 (project findutils): > - cmd | find -files0-from - is potentially dangerous if cmd ends up being aborted for instance because it reaches some resource limits. For instance it was going to output /tmp/x/foo\0/tmp/x/bar\0 but got aborted just after it wrote /tmp/x/

[bug #60383] [feature-request] let find read files from stdin or file.

Follow-up Comment #17, bug #60383 (project findutils): > it seems just to ensure that the next argv[i] is treated as a starting point > (regardless whether it looks like an option or not). > Furthermore, -f seems to change the handling of the '--' argument. > > This seems to be a solution for the

[bug #60383] [feature-request] let find read files from stdin or file.

Follow-up Comment #15, bug #60383 (project findutils): Thanks Bernhard. I think it's a more useful API like that. BTW, would you also consider adding BSD's -f to GNU find? I don't think POSIX would agreed to specify -files0-from, like they rejected -print0 on the ground that most POSIX utilities

[bug #60383] [feature-request] let find read files from stdin or file.

Follow-up Comment #11, bug #60383 (project findutils): I very much welcome that new feature, as that at last fixes the long standing issue that you can't pass arbitrary file paths to "find" (such as "-my-file-", "(", "!" which you need to prefix with ./ as a work around, see also the (clunkier to

[bug #42501] Add -E option for FreeBSD/Mac OSX compatibility

Follow-up Comment #4, bug #42501 (project findutils): I would also love to see -E added to GNU find. [comment #3 comment #3:] > I'm happy to implement this option as long as we can nail down which regex dialect -E should select. Is there any chance you could provide more detail on your answer t

[bug #60207] -prune returns false for files for which fstatat() fails with EACCESS

Follow-up Comment #3, bug #60207 (project findutils): [comment #2 comment #2:] [...] > In parser.c, we see that -prune adds it unless -depth is set: [...] > And indeed, adding -depth doesn't yield the extra "[call stat] [need type]". [...] Note that in any case, -prune can't be used (is ineffecti

[bug #60207] -prune returns false for files for which fstatat() fails with EACCESS

Follow-up Comment #1, bug #60207 (project findutils): For the record, comparison with other find implementations on that second (symlink-based) example on the same system: $ gnu-find -L . -name 'a*' -prune -o -print . ./b1 find: ‘./a1’: Permission denied ./a1 ./b2 find: ‘./a5’: Not a directory f

[bug #60207] -prune returns false for files for which fstatat() fails with EACCESS

URL: Summary: -prune returns false for files for which fstatat() fails with EACCESS Project: findutils Submitted by: stephanechazelas Submitted on: Wed 10 Mar 2021 12:17:47 PM UTC Cat

Re: Is there a way to let find return non-zero when nothing is found?

2019-11-14 08:19:19 +, Stephane Chazelas: [...] > if [ "$(kill -l "$?")" -eq PIPE ]; then... [...] Sorry, should have been: if [ "$(kill -l "$?")" = PIPE ]; then... -- Stephane

Re: Is there a way to let find return non-zero when nothing is found?

2019-11-12 23:54:45 +0100, Bernhard Voelker: [...] > I see the following in 'man find' on NetBSD 8.0: > > -exit [status] [...] > (Interestingly, NetBSD-find does not have -quit.) -exit was added there in 2006. GNU's -quit was added in 4.2.3 (2004) so that makes GNU's -quit the first indeed.

Re: Is there a way to let find return non-zero when nothing is found?

2019-11-11 17:45:03 +0800, Peng Yu: > Hi, > > Sometimes, I'd like to know whether there is nothing found. Is there a > way to let find return none-zero when nothing is found? Thanks. [...] If using -print, you can pipe to grep '^' if find ... | grep '^'; then echo "find found something, see li

[bug #57025] find -mtime will ignore large files

Follow-up Comment #1, bug #57025 (project findutils): Please provide with some steps to reproduce it. I can't reproduce on Ubuntu 18.04.3 here with: $ truncate -s 15T a $ find . -mtime -1 -ls 59965646 4 drwxrwxr-x 2 me me 4096 Oct 9 20:29 . 59912668 0 -rw-rw-r-- 1 me m

Re: The quickest way to not to descend into sub-directories once a file is found?

2019-10-02 17:10:25 -0500, Peng Yu: > I’ve checked this many years ago. One directory exec is not acceptable in > my case. I ended up with two pass, one to check which directory to include > and exclude, then search for files in the directory included. But I am > looking for something better. [...]

Re: The quickest way to not to descend into sub-directories once a file is found?

2019-09-26 21:57:09 -0500, Peng Yu: [...] > I'd like to find files named `file.txt` recursively. But the directory > structure has a property that if any directory has a file `file.txt`, > any of its subdirectories will not have file.txt anymore. > > Therefore, the quickest way to `find` is to sto

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

Follow-up Comment #1, bug #56855 (project findutils): There is also a case for having the empty string there. If it was the case for %f as well, that would mean that -printf %h/%f would always be equivalent to -printf %p More importantly, in cases like: find / -name foo -printf '%h/bar\0' | x

Re: [CLEAR] alias find issue

2016-09-06 15:39:47 +0200, Julien Rivoal: [...] > I have a question for an aliases utilization, I use since a long times this > alias : alias ff='find . -name "\!*" -print' [...] You're confusing csh with sh. alias ff 'find . -name "\!*" -print' Is a csh dirty hark using history expansion to hav

[PATCH] incomplete fix for savannah#26092

-ipath is no longer deprecated. https://savannah.gnu.org/bugs/?26092 There's still one mention of -ipath being deprecated in the texinfo documentation. Note that someone just requested -iname be added to POSIX: http://austingroupbugs.net/view.php?id=1031 diff --git a/doc/find.texi b/doc/find.t

Re: find -L -execdir (Was: "find" ends with exit code "0" although exec command returned an error)

2015-12-22 15:58:33 +, James Youngman: [...] > Trying your example with recent find code ($PWD here is the root of a > freshly built findutils tree), though, I don't get the same result. > It looks to me as if the the behaviour you're describing is a > previously reported and fixed bug > (https

find -L -execdir (Was: "find" ends with exit code "0" although exec command returned an error)

2015-12-20 18:30:36 +, James Youngman: > On Fri, Dec 18, 2015 at 11:43 PM, Stephane Chazelas > wrote: > > > At that Q&A, we also discuss the behaviour of GNU find when both > > -L and -execdir are used for which I think at least the > > documentation could

Re: "find" ends with exit code "0" although exec command returned an error

2015-12-18 22:55:56 +, James Youngman: > I've updated the documentation to make this clearer. [...] Thanks. BTW, (and it might have been what have prompted you to revisit that old thread), I've just raised two related questions on the austin group mailing list: http://thread.gmane.org/gmane.c

[PATCH] typo (missing space in example) in find documentation

There's a missing space between {} and \; in one of the examples. diff --git a/doc/find.texi b/doc/find.texi index bd1d6a1..3214cdc 100644 --- a/doc/find.texi +++ b/doc/find.texi @@ -5144,7 +5144,7 @@ problem: @example # safer find -exec sh -c 'something "$@@"' sh @{@} \; -find -execdir sh -c '

Re: "find" ends with exit code "0" although exec command returned an error

In the case of: find ... -exec cmd {} \; The exit status of cmd is used to determines whether the predicate evaluates to true or false. For instance: find . -exec test -d {} \; -print Would print the paths of the files that are directories or symlink to directories, the standard equivalent of

Re: Why xargs still call the command when there is no input?

2015-06-02 21:59:22 -0600, Eric Blake: > On 06/02/2015 04:02 PM, Peng Yu wrote: > > The following command will call ls. But since there is no input, > > shouldn't xargs quit without doing anything? Thanks. > > > > xargs -0 ls > Try: > > xargs -r -0 ls > Per POSIX, the behavior of one-or-more

Re: Filename Expansion: Find Utility Pattern Matching vs Bash Shell Pattern Matching

2015-06-16 12:02:33 -0700, Michael Convey: > For filename expansion, the 'find' utility's '-name' option seems to > function similarly, but not exactly the same as the bash shell's builtin > pattern matching. > > Here are the relevant sections of the GNU reference manual: > >- Bash shell patt

Re: [bug #18714] and also seen as separators by GNU xargs

On Sat, Jan 13, 2007 at 09:25:04PM +, James Youngman wrote: > On 1/13/07, Stephane Chazelas <[EMAIL PROTECTED]> wrote: > >BTW, please disregard #18715, I had misread the documentation > >and specification. > > Hmm. What did you read that changed you mind? [...]

Re: [bug #18714] and also seen as separators by GNU xargs

On Sat, Jan 13, 2007 at 06:49:26PM +, James Youngman wrote: > > Update of bug #18714 (project findutils): > > Status: In Progress => Fixed > > ___ > > Follow-up Comment #2: > > Fixed in