Re: Possible bug with -size and a one

On 2025-06-07 Scott Baker wrote: > I'm trying to find all the files in /tmp/ that less than 1MB. > mkdir /tmp/scott > cd /tmp/scott > echo "Hello world" > test.txt > find . -size -1M -type f    # doesn't work > find . -size -2M -type f    # works > find . -size -1024k -type f # works > From what

[bug #67135] find -ls output is ASCII-only even in UTF-8 locales

4.9.0 Fixed Release: None ___ Follow-up Comments: --- Date: Sa 17 Mai 2025 13:15:14 CEST By: Andreas Metzler Hello, this was originally reported as <https://bugs.debian.or

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

Follow-up Comment #3, bug #46791 (group findutils): Quoting Chris Dunlop on https://bugs.debian.org/397434 Just to add a voice... My use case is to search for all the alternate paths to a specific device. I was quite surprised to discover that find doesn't support searching by major:minor, to t

[bug #65998] xargs strange behavior

Follow-up Comment #1, bug #65998 (group findutils): Hello, xargs is executing "echo" (since no command was given), which swallows/uses the -e an -n options. If you replace "xargs" with "xargs printf '%s\n' in your examples you will see that xargs passes everything along to the command. cu Andre

[bug #65895] Expression order matters?

Follow-up Comment #1, bug #65895 (group findutils): find(1) has this at the very start [...] by evaluating the given expression *from left to right*, according to the rules of precedence and later an extra warning about -delete: *ACTIONS* _-delete_ Delete files or directories; true

[bug #65812] make dist includes bnary file

elease: None ___ Follow-up Comments: --- Date: Thu 30 May 2024 11:52:46 AM CEST By: Andreas Metzler Hello, with current GIT head the compiled binary tests/xargs/test-sigusr is shipped a

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

On 2023-12-02 Mannem Anil kumar wrote: > Dear Concern, > As i was exploring Linux related commands, i > have executed the following command in terminal. Where that file is not > existed and find command not says that file is not found. >

[bug #64857] find -ctime, -cnewer etc does not work

Follow-up Comment #2, bug #64857 (project findutils): The special thing to keep in mind is that -cnewer compares the *mtime* of the reference file with the _ctime_ of the tested files. ___ Reply to this item at:

Re: Excluding future-dated files in 'find' on Cygwin

On 2023-10-20 Backwoods BC wrote: > On Fri, Oct 13, 2023 at 7:55 AM Andreas Metzler wrote: > > On 2023-10-13 Backwoods BC wrote: > > [...] [...] > TFM says: > -atime n > File was last accessed less than, more than or exactly n*24 hours ago. > When find figures out h

Re: Excluding future-dated files in 'find' on Cygwin

On 2023-10-13 Backwoods BC wrote: [...] > find ./ -mtime +0 -mtime -1 > but this found nothing. When I changed it to: > find ./ -mtime 0 -mtime -1 > it worked as desired and found all files less than a day old and not > future-dated. > Can someone tell me, please, if this is a bug or the expec

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

On 2023-09-12 Peng Yu wrote: > Hi, > How to find directories that only contain a certain type of files (e.g., > .txt)? > One idea that I have is to just search for all files' paths. Then use > a post-processing script to analyze which directories only contain > files of a certain type (e.g., .t

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

On 2023-06-02 raf wrote: > On Thu, Jun 01, 2023 at 07:14:55PM +0200, Andreas Metzler > wrote: [...] > > file reads from $(datadir)/misc and libmagic-mgc ships > > /usr/lib/file/magic.mgc which is symlinked to /usr/share/misc/magic.mgc. > > > > cu Andreas > &

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

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. [...] file reads from $(datadir)/misc and libmagic-mgc ships /usr/lib/file/magic.mgc which is symlinked to /usr/share/misc/magic.mg

Re: find: print trailing slash for directories

On 2022-08-06 Fourhundred Thecat <400the...@gmx.ch> wrote: > Hello, > how difficult would it be to patch find, to print trailing slash for > directories? [...] No patching required. ametzler@argenau:/tmp/findtest$ find \( -type d -printf '%p/\n' \) -or \( -print \) ./ ./symlink1 ./file1 ./file2

[patch #10203] build error on musl due to old gettext infrastructure

URL: Summary: build error on musl due to old gettext infrastructure Project: findutils Submitted by: ametzler Submitted on: Sat 23 Apr 2022 02:13:58 PM CEST Category: None

Re: Patches to findutils 4.9.0-1's updatedb to do locking, allow filenames with spaces & progress monitoring, exclude /dev on Cygwin, etc.

On 2022-02-24 Dan Harkless wrote: > Howdy.  I posted last August to the Cygwin list about some problems I was > having with the updatedb script, including that it was taking more than 24 > hours to complete, and then colliding with the next cron run, and that I had > no way to monitor progress (sh

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

Follow-up Comment #7, bug #62043 (project findutils): [comment #5 comment #5:] by Jay > [comment #4 comment #4:] Andreas writes: >> OTOH I am trying to fix the documentation of xargs' >> inconsistent behavior, imho these two commands should produce >> identical output both for consistency reasons

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

Follow-up Comment #4, bug #62043 (project findutils): [comment #3 comment #3:] by Stephane Chazelas > 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

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

Follow-up Comment #2, bug #62043 (project findutils): How about the following change: diff --git a/xargs/xargs.1 b/xargs/xargs.1 index f743e60c..d0d54bfa 100644 --- a/xargs/xargs.1 +++ b/xargs/xargs.1 @@ -240,8 +240,12 @@ once child processes exit. This can be used in a rudimentary load dist

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

Follow-up Comment #1, bug #62043 (project findutils): This a duplicate of bug #61356 cu Andreas ___ Reply to this item at: ___ Message sent via Savann

Re: doc: Capitalize parameter of -[x]type.

On 2022-02-07 Nikolaos Chatzikonstantinou wrote: > From f3f0b85cb343fa882987beac4fff3bf57a1039bc Mon Sep 17 00:00:00 2001 > From: Nikolaos Chatzikonstantinou > Date: Mon, 7 Feb 2022 18:11:03 +0900 > Subject: [PATCH] doc: Capitalize parameter of -[x]type. > The parameter of -type and -xtype was l

[bug #61774] Docs for find -delete out of sync

Follow-up Comment #2, bug #61774 (project findutils): [comment #1 comment #1:] > Thanks for the report and the suggested patch. [...] > I tried further to improve and unify the -delete description > in the attached git patch. Thank you! Docs are nicely in sync. > Okay to push in your name? I t

[bug #61774] Docs for find -delete out of sync

URL: Summary: Docs for find -delete out of sync Project: findutils Submitted by: ametzler Submitted on: Sat 08 Jan 2022 06:38:08 PM CET Category: documentation Severit

Re: strange behavour with combining -i with -n 1 for xargs

On 2021-10-22 "Koopal, Andre via Bug reports for the GNU find utilities" wrote: > I tried the following which didn't work as expected: > % echo a b c | gxargs -n 1 -i echo before {} after > before a b c after [...] > This seems like a bug to me, can you investigate? Hello, -I replace-str

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

Follow-up Comment #1, bug #61356 (project findutils): Not a bug, see https://lists.gnu.org/archive/html/bug-findutils/2021-05/msg6.html ___ Reply to this item at: __

Re: Can the locate database / locate tool report file size?

On 2021-07-31 Colin Williams wrote: > Can the locate database / locate tool be configured to report file size? Hello, The database only stores filenames. See locatedb(5). You could combine locate with xargs and e.g. ls to print more information on the matching files. ametzler@argenau:~$ locate

Re: The xargs -r, --no-run-if-empty Option Is Ignored When a Delimiter Is Passed

On 2021-05-11 Kurt von Laven wrote: > Hello, > When the -r, --no-run-if-empty option is combined with the -d, --delimiter > or -0, --null options, the -r, --no-run-if-empty option does not > take effect. The manual describes the intended behavior of the -r, > --no-run-if-empty option: "If the sta

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

Follow-up Comment #5, bug #60383 (project findutils): [comment #1 comment #1:] [...] > For a most-secure way, i.e., to avoid surprises with unusual file names, > the input file should contain the entries separated by NUL characters. I actually think if you are extending find in this non-portable

[bug #59745] Issues in findutils manpages

Follow-up Comment #7, bug #59745 (project findutils): [comment #6 comment #6:] [...] > They create a 1/6th em space, and therefore act as a visual thousands- > separator to ease reading of larger numbers. > Andreas patch would remove them: > > -.BR "\-size \-1\|048\|576c". > > +.BR "\-size \-104

[bug #59745] Issues in findutils manpages

Follow-up Comment #5, bug #59745 (project findutils): [comment #4 comment #4:] > [comment #3 comment #3:] [...] >> ametzler@argenau:/tmp/findtest$ touch fil1.c fil2.c >> ametzler@argenau:/tmp/findtest$ find . -name *.c -print >> find: paths must precede expression: `fil2.c' >> find: possible unquo

[bug #59745] Issues in findutils manpages

Additional Item Attachment, bug #59745 (project findutils): File name: 2nd_version_patch.diff Size:2 KB ___ Reply to this item at:

[bug #59745] Issues in findutils manpages

Follow-up Comment #3, bug #59745 (project findutils): Hello Helge, On 2020-12-27 Helge Kreutzmann wrote: > Follow-up Comment #2, bug #59745 (project findutils): [...] >>> Man page: find.1 >>> Issue: Superflous space in first line >>> "The %m and %d directives support the B<#> , B<0> and B<+> fla

[bug #59745] Issues in findutils manpages

Additional Item Attachment, bug #59745 (project findutils): File name: typo.fixes.diffSize:2 KB ___ Reply to this item at:

[bug #59745] Issues in findutils manpages

Follow-up Comment #1, bug #59745 (project findutils): On 2020-12-21 Helge Kreutzmann wrote: [...] > Secondly we translators see the manpages in the neutral po format, > i.e. converted and harmonized, but not the original source (be it man, > groff, xml or other). So we cannot provide a true patch

Re: Imprecision in documentation of -newer

On 2020-11-21 Reuben Thomas via Bug reports for the GNU find utilities wrote: > The manual (current git) says: > True if the time of the last access (or status change or data modification) > > of the current file is more recent than that of the last data modification > > of the @var{reference} f

[bug #59330] Trivial formatting fixes for manpages

URL: Summary: Trivial formatting fixes for manpages Project: findutils Submitted by: ametzler Submitted on: Sat 24 Oct 2020 02:06:59 PM CEST Category: documentation Se

[bug #58205] Double dash option (--) mentioned only in manpage, unclear/nonworking

Follow-up Comment #4, bug #58205 (project findutils): [comment #3 Bernhard Voelker wrote in comment #3:] > Thanks for your comments. > I suggest the attached documentation change. [...] > (file #49666) Looks good. Thank you! cu Andreas __

[bug #58654] -perm -+w does not behave like chmod (POSIX)

Follow-up Comment #2, bug #58654 (project findutils): [comment #0 Mohamed Akram:] [...] > Per POSIX, find should find file because it satisfies +w given the current umask. The umask should only be ignored if u/g/o are specified or if = is used. This is the same behavior as chmod. GNU find seems to

[bug #58205] Double dash option (--) mentioned only in manpage, unclear/nonworking

Follow-up Comment #2, bug #58205 (project findutils): Bernhard Voelker wrote: > Andreas Metzler wrote [...] > The "--" separates the options from the rest of the call arguments, > which for find(1) could be path arguments followed by predicates > (i.e. tests and actions).

[bug #58541] [wishlist] Add optional sort to find

Follow-up Comment #3, bug #58541 (project findutils): [comment #2 Lady Aleena:] > [comment #1 Andreas Metzler:] > > Just use > > find -type f -print0 | sort -fnr --zero-terminated | xargs -r0 whatevercommand > > I did that, but it would be nice not to have to pipe so much.

[bug #58541] [wishlist] Add optional sort to find

Follow-up Comment #1, bug #58541 (project findutils): Just use find -type f -print0 | sort -fnr --zero-terminated | xargs -r0 whatevercommand ___ Reply to this item at:

[bug #58384] incorect documentaion for -regex

Follow-up Comment #1, bug #58384 (project findutils): Read on a litte bit: There are several varieties of regular expressions; by default this test uses POSIX basic regular expressions, but this can be changed with the option @samp{-regextype}. __

Re: How to search for file with size >= a given size?

On 2020-05-10 Peng Yu wrote: > Hi, > I only see find's --size support + and - which means > or <. Is there > a way to search for >= or <=? Thanks. There is a generic -not. - "not >" == "<=" cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.

[bug #58149] Whitespace parsing differs with and without -i

Follow-up Comment #1, bug #58149 (project findutils): That is documented behavior. -i[replace-str], --replace[=replace-str] This option is a synonym for -Ireplace-str if replace-str is specified. [...] -I replace-str Replace occurrences of replace-str in the initia

Re: specify a multiple of m arguments in xargs

On 2020-03-08 Peng Yu wrote: > I don't think the `xargs -n 4` in the middle is robust. For example, > when the input contains spaces, it won't work as expected. Is there a > way to make it robust? NUL as delimiter? cu Andreas

Re: Language lawyering the man pages

On 2020-01-29 Álvaro António Santos wrote: > The man pages for find (version 4.7.0-git) say the following at the > end of the "EXPRESSION" section: > If the whole expression contains no actions other than -prune or > -print, -print is performed on all files for which the whole > expression is true

Re: distribution tarball format [was: Announcing the release of GNU findutils 4.7.0]

On 2019-09-03 Bernhard Voelker wrote: > On 8/31/19 9:59 AM, Antonio Diaz Diaz wrote: [...] > > Bernhard Voelker wrote: > >> "make dist" no longer builds .tar.gz files. > >> xz is portable enough and in wide-enough use that distributing > >> only .tar.xz files is enough. > > > > It may be enough b

[bug #48135] samefile-p-brokenlink.exp fails on Hurd and BSD

Follow-up Comment #2, bug #48135 (project findutils): [comment #1 comment #1:] > I applied your patch, making a tweak to the wording and adding an update to the NEWS file. The result is https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=c31ef289899fb06777cdf97fd8e2bf8b22fa49cc Thank you

Re: find: ... -ok rmdir ... No such file or directory

On 2019-07-28 積丹尼 Dan Jacobson wrote: > Please make this not make error messages. > # mkdir /tmp/nnn > # mkdir /tmp/nnn/ooo > # find /tmp/nnn -type d -ok rmdir {} \; > < rmdir ... /tmp/nnn > ? > < rmdir ... /tmp/nnn/ooo > ? y > find: ‘/tmp/nnn/ooo’: No such file or directory > # find /tmp/nnn -typ

[bug #56410] find -L doesn't follow symlinks outside the specified search scope

Follow-up Comment #15, bug #56410 (project findutils): Bernhard Voelker wrote: > I'm trying to find the documentation which would make you as a our user think that -L would let -print or "-exec ... {}' +" use the resolved path name. I think the description of -L very clearly states this: -L

[bug #56198] Typo in xargs.1: 'ouptut'

Follow-up Comment #1, bug #56198 (project findutils): This was fixed in 2016. https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=85e8c810a29cca8faea6cbd93169cf7051cd65b5 ___ Reply to this item at:

Re: Document that find -maxdepth is a GNU extension

On 2019-04-15 Bernhard Voelker wrote: > On 4/15/19 7:02 PM, Дилян Палаузов wrote: > > this information is in the manual page, but not in the info files. The > > latter state e.g. for --no-run-if-empty, that > > this is a “GNU extension”. > Actually, there's a lot redundancy between the man page

Re: Document that find -maxdepth is a GNU extension

On 2019-04-15 Дилян Палаузов wrote: > Hello, > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html (Open > Group Base Specifications Issue 7, 2018 > edition) does not mention for find the -maxdepth option. > • write in the documentation for -maxdepth that this is a GNU extension

Re: find command has a bug?

On 2019-01-13 zcj5918 wrote: > I think find has a bug that can be launched by combining several > commands together, in that it chokes by generating an erroneous report > when I use inode to delete a directory, although it does remove the > corresponding directory correctly. > Please see what ha

[bug #55272] wrong use of quotes in the error message

Follow-up Comment #1, bug #55272 (project findutils): grrr. savanah swallowed half of the bug-report. Rich-text without preview suck. Anyway find . -name phc/\*.tex The output is: find: warning: Unix filenames usually don't contain slashes (though pathnames do). That means that '-name `phc/

[bug #55272] wrong use of quotes in the error message

URL: Summary: wrong use of quotes in the error message Project: findutils Submitted by: ametzler Submitted on: Sun 23 Dec 2018 04:18:41 PM CET Category: None Severity:

[bug #55095] please add "--count" to find

Follow-up Comment #1, bug #55095 (project findutils): FWIW I think this is a terrible idea. Combining find and wc to count matches (a) works very well and (b) is accessible. People who know the basic find syntax and know the existence of wc will do it exactly this way, instead of looking into find

[bug #54913] find: "-type"-test wrong on bind-mounted char device

URL: Summary: find: "-type"-test wrong on bind-mounted char device Project: findutils Submitted by: ametzler Submitted on: Mon 29 Oct 2018 06:59:31 PM CET Category: find

[bug #54856] A Bit Unclear -execdir Documentation

Follow-up Comment #1, bug #54856 (project findutils): Where are you reading that and in which version of find? find.1 in GIT has a very verbose wording already. - Like -exec, but the specified command is run from the subdirectory containing the matched file, which is not normall

[bug #54171] find -depth skips unreadable directories

Follow-up Comment #3, bug #54171 (project findutils): Hello, find attached a patch for extending the testsuite to cover this bug. (file #44465) ___ Additional Item Attachment: File name: 0001-tests-test-find-depth-with-unreadable-director

[bug #54171] find -depth skips unreadable directories

Follow-up Comment #1, bug #54171 (project findutils): Just ran through all the binaries I had lying around: The problem is not present in oldfind, but was already present in 4.5.15. ___ Reply to this item at:

Re: -execdir '{}' \; vs -execdir '{}' +

On 2018-02-03 Андрей Веселов wrote: > # cd test > # ls -1 > file1 > file2 > file3 > # find . -type f -exec echo -n '{}' + > ./file1 ./file3 ./file2 > # find . -type f -exec echo -n '{}' \; > ./file1./file3./file2 > # find . -type f -execdir echo -n '{}' + > ./file1./file3./file2 > # find . -type f

Re: [PATCH] maint: use an optimal-for-findutils xz compression setting

On 2017-10-29 Bernhard Voelker wrote: > On 10/28/2017 08:06 PM, Andreas Metzler wrote: [...] > > OTOH -7e is almost two times *slower* than the default. 5.74 seconds vs > > 3.77 on i5-6500. > This is the time for creating the compressed tarball, right? This is done > only o

Re: [PATCH] maint: use an optimal-for-findutils xz compression setting

On 2017-10-28 Bernhard Voelker wrote: > * cfg.mk: Set XZ_OPT = -7e (determined empirically). > The compressed tarball size is identical to the default settings (-9e), > but using -9e would force every decompression process to use 48 MiB > more memory. [...] Hello, I do not think this is a good t

[bug #52137] unexpected behaviour when combining -I and -n

Follow-up Comment #6, bug #52137 (project findutils): > I squashed the commits into one, and changed the following: > - use error() rather than fprintf(), I tried that first but it broke the testsuite because error() always outputs argv[0] and argv[0] will include the path when run from testsuite

[bug #52137] unexpected behaviour when combining -I and -n

Follow-up Comment #4, bug #52137 (project findutils): Hello, find attached a patch series to - improve documentation for conflicting options - make xargs display a warning on conflicting options - increase coverage for these options. cu Andreas (file #42093, file #42094, file #42095) __

[bug #52137] unexpected behaviour when combining -I and -n

Follow-up Comment #3, bug #52137 (project findutils): Hello, agreed regarding addition of warning and doc-update. > "But I cannot see posix requiring that -I and -n must produce > strange results, so xargs could go beyond posix and produce > correct results in that case anyway." Actually POSIX

[bug #52137] unexpected behaviour when combining -I and -n

Follow-up Comment #1, bug #52137 (project findutils): Posix says: "The -I, -L, and -n options are mutually-exclusive. Some implementations use the last one specified if more than one is given on a command line; other implementations treat combinations of the options in different ways." GNU xargs

[bug #51841] find buffer-overflow with -printf '%T+'

Follow-up Comment #8, bug #51841 (project findutils): Hello, set env(TZ) "UTC" indeed works. normal braces, not curly ones. Thanks. Fixed patch attached. (file #41763) ___ Additional Item Attachment: File name: works_nonUTC_Test-more-pri

[bug #51841] find buffer-overflow with -printf '%T+'

Follow-up Comment #6, bug #51841 (project findutils): Well actually there is a simple way: --- a/find/testsuite/Makefile.am +++ b/find/testsuite/Makefile.am @@ -24,6 +24,8 @@ FINDFLAGS = DEJATOOL = find +export TZ = UTC + I'll post an updated patch. cu Andreas __

[bug #51841] find buffer-overflow with -printf '%T+'

Follow-up Comment #5, bug #51841 (project findutils): On 2017-09-06 Bernhard Voelker wrote: > It seems they fail here: > -l1 1990-06-22+14:00:00.00 646056000.00 [...] > +l1 1990-06-22+12:00:00.00 646056000.00 [...] > The expected output fo

[bug #51841] find buffer-overflow with -printf '%T+'

Follow-up Comment #3, bug #51841 (project findutils): Hello, find attached a patch to check %T* (limited to strftime sequences mandated by POSIX), %M, %t, %y, and %Y in the testsuite. Works for me (on Debian GNU/Linux). cu Andreas (file #41718) _

[bug #51841] find buffer-overflow with -printf '%T+'

URL: Summary: find buffer-overflow with -printf '%T+' Project: findutils Submitted by: ametzler Submitted on: Thu 24 Aug 2017 07:54:37 PM CEST Category: find Severity:

Re: bug-findutils Digest, Vol 173, Issue 2

On 2017-08-12 Aman ulla wrote: > but,still its showing below error.. Kindly help us to resolve.. > $find /user/home/ -mindepth 1 -type f -not -name '.*' -delete && find > /user/home/ -type d -not \ (-name '.*' -or -name 'Desktop' -or -name > 'thinclient_drives' \) -delete > find: paths must prec

[bug #51304] Documention refers to kibibytes as kilobytes

URL: Summary: Documention refers to kibibytes as kilobytes Project: findutils Submitted by: ametzler Submitted on: Sat 24 Jun 2017 02:03:23 PM CEST Category: documentation

[bug #51151] [wishlist] xargs -o support for interactive commands

Follow-up Comment #9, bug #51151 (project findutils): On 2017-06-06 Thorsten Glaser wrote: > 3. In Andreas’ patch, obviously, do not remove the reword it slightly. > Rationale for #2 and #3: while the BSD extension is added, documenting this is > likely still good for when one searches the docu

[bug #51151] [wishlist] xargs -o support for interactive commands

Follow-up Comment #7, bug #51151 (project findutils): Hello Bernhard, I think some more changes to the documentation would be a good thing. There are a couple of examples on how to jump through hoops because -o was not available. Suggested patchlet (to go on top of yours) included. Andreas (file

[bug #51151] [wishlist] xargs -o support for interactive commands

Follow-up Comment #2, bug #51151 (project findutils): On 2017-06-01 Bernhard Voelker wrote: > isn't [...] > $ xargs -0n1 -a <(find -type f -print0) vi > what you are looking for? [...] Afaict it fullfills the same purpose. However it requires using a specific shell (bash). __

[bug #51151] [wishlist] xargs -o support for interactive commands

URL: Summary: [wishlist] xargs -o support for interactive commands Project: findutils Submitted by: ametzler Submitted on: Wed 31 May 2017 07:37:17 PM CEST Category: xargs

Re: Documentation of -atime, etc.

On 2017-04-01 "Dale R. Worley" wrote: > I was looking at an old sandbox I have that contains some partially-made > changes to the documentation of -atime and related predicates. > In find.texi is: > @deffn Test -atime [+|-]n > @deffnx Test -ctime [+|-]n > @deffnx Test -mtime [+|-]n >

Re: RFE: allowing "" as a path specification for 'current dir' w/o prepending './' ?

On 2017-03-03 Eric Blake wrote: [...] > So while I'm okay with something like: > find --trim-leading-dot > printing 'foo' instead of './foo', (and where you can wrap a function or > alias around it to always turn --trim-leading-dot on for your own > interactive dot), I am NOT okay with: > find

[bug #50326] Memory leak due to missing me_mntroot deallocation

Follow-up Comment #1, bug #50326 (project findutils): Possibly related to http://lists.gnu.org/archive/html/findutils-patches/2017-02/msg00020.html i.e. caused by a btrfs bug. ___ Reply to this item at:

[bug #48314] find -type f matches symlinks in armel armhf and mipsel

Follow-up Comment #2, bug #48314 (project findutils): I have been wondering why the testsuite did not detect this and have found that the issue does not show up if -maxdepth is used. Find attached a trivial two-patch series to detect the bug: 0001-Test-checked-for-features-in-installed-find.patc

[bug #48314] find -type f matches symlinks in armel armhf and mipsel

Follow-up Comment #1, bug #48314 (project findutils): Hello, this is https://bugs.debian.org/827724 originally submitted by Maximiliano Curia: -- The new version of find has a weird behaviour, at least in the arches: armhf armel and mipsel. As simple test: dir=$(mktemp -d

[bug #48314] find -type f matches symlinks in armel armhf and mipsel

URL: Summary: find -type f matches symlinks in armel armhf and mipsel Project: findutils Submitted by: ametzler Submitted on: Sat 25 Jun 2016 12:45:15 PM CEST Category: find

[patch] implicit declaration of function 'explain_how_to_report_bugs'

p 17 00:00:00 2001 From: Andreas Metzler Date: Sat, 28 May 2016 14:44:32 +0200 Subject: [PATCH] fix implicit declaration of function warning. * find/parser.c do not #include "bugreports.h" - it was unused. * find/util.c: add #include "bugreports.h". --- find/parser.c | 1 - find/u

[bug #48030] -exec + does not pass all arguments for ceratin specific filename lengths

Follow-up Comment #4, bug #48030 (project findutils): This also applies to oldfind from 4.4.2. ___ Reply to this item at: ___ Nachricht gesendet von/dur

Uploaded GIT head to Debian/unstable

Hello, FYI I have uploaded findutils GIT head (with gnulib GIT head) as of 2016-02-26 to Debian unstable. The major incentive for this step was http://bugs.debian.org/812762 a gnulib related testsuite error in some locales. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His oth

Re: Error installing libpython3.4-minimal_3.4.4-1_amd64.deb (Ubuntu xenial)

On 2016-02-07 Bill Ward wrote: > Reading package lists... Done > Building dependency tree > Reading state information... Done > 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not > upgraded. > Need to get 0 B/466 kB of archives. > After this operation, 0 B of additional disk space

Re: installation errors

On 2016-01-23 Michael Grant wrote: > I received the following this morning when doing an apt-get upgrade. It > seems to be when installing python but the message below asks that I send > mail to bug-findutils. > ... > Preparing to unpack .../python3.4_3.4.4-2_amd64.deb ... > xargs: invalid numbe

Re: Comunicar errores a .Desinstalando libpython3.4-stdlib:amd64 (3.4.4-1) ...

On 2016-01-19 Javier Fernandez wrote: > test@test-MS-9A55:~$ sudo apt autoremove > Leyendo lista de paquetes... Hecho > Creando árbol de dependencias > Leyendo la información de estado... Hecho > Los siguientes paquetes se ELIMINARÁN: > checkbox-ng liblouis2 libpython3.4-minimal libpython3.4-std

Development and release model? - Multiple branches? (was: [PATCH 0/8] maintenance patches)

On 2016-01-04 James Youngman wrote: > On Mon, Jan 4, 2016 at 8:11 AM, Bernhard Voelker > wrote: [...] >> b) Do you want me to push to the 4.6 branch, too? (see c)). >> c) Will we maintain a 4.6 and a 4.7 line in parallel (although >> we don't have anything big for master)? I must confess that >

Old request 267658 Emphasize operator precedence for "a" over "-o" in manpage

Hello, I have been looking on old Debian bugs and have stumbled over 267658 (wishlist!): | Come to think of it some reminder in man page for the operator | precedence will be nice. This would be easy to implement by adding an example: --- a/find/find.1 +++ b/find/find.1 @@ -1505,7 +1505,13 @@ a

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

URL: Summary: wishlist: no option to find devices for major/minor Project: findutils Submitted by: ametzler Submitted on: Sa 02 Jan 2016 14:24:08 CET Category: find Se

[patch] Minor doc updates

and again, expand doc a little bit. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' >From 6f10f15569dac6cbb9fda51fb88e39e9556f5d55 Mon Sep 17 00:00:00 2001 From: Andreas Metzler Date

[bug #46784] frcode drops last char if no final newline

URL: Summary: frcode drops last char if no final newline Project: findutils Submitted by: ametzler Submitted on: Do 31 Dez 2015 14:25:08 CET Category: updatedb Severity

Re: Proposed release announcement for findutils-4.6.0 - request for comments

On 2015-12-27 James Youngman wrote: [...] > 1. Some backward-incompatible changes have been made to find: > - egrep regular expressions now work like GNU grep -E > - Minor changes to the way nanoseconds fields are printed > - find -perm +mode is now fully POSIX compliant (if you > want t

[patch] Use official FDL license grant

Hello, find attached a trivial patch against GIT head to use the official FDL license wording as listed in FDL's "ADDENDUM: How to use this License for your documents". cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on fr

[Patches] Typo and formatting fixes for find.1 by Bjarni Ingi Gislason

grateful to you.' `I sew his ears on from time to time, sure' >From 8eebb23560045f298287ac898f26be50bc7c785b Mon Sep 17 00:00:00 2001 From: Andreas Metzler Date: Thu, 24 Dec 2015 16:31:17 +0100 Subject: [PATCH 1/2] Typo and grammar fixes. Issue reported by and patch provided by Bjarni

[patch] Fix another bashism

:00 2001 From: Andreas Metzler Date: Thu, 24 Dec 2015 16:02:55 +0100 Subject: [PATCH] Fix bashism ([[ ... ]] instead of [ ... ]). --- find/testsuite/test_escape_c.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/find/testsuite/test_escape_c.sh b/find/testsuite/test_esca

  1   2   3   >