Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

On 2025-07-10 03:31, James Youngman wrote: Do we need to notify the Emacs maintainers about what is happening (or did happen)? No, as they inspired the Gnulib change in the first place. See .

Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

Do we need to notify the Emacs maintainers about what is happening (or did happen)?

Re: regexprops-generic propagation

Bernhard Voelker wrote: > still it can take some months sometimes from a change in regex.h > until updating the gnulib submodule in findutils ... Oh, so a change in regex.h (in gnulib) propagates to a change in regexprops-generic.texi (in gnulib) via some tool that lives in the findutils repositor

Re: regexprops-generic propagation

On 7/10/25 07:56, Bruno Haible wrote: Bernhard Voelker wrote: * [PATCH 2/3] regexprops: sort regex_map alphabetically https://cgit.git.sv.gnu.org/cgit/findutils.git/commit/?id=c9c2c511759 * [PATCH 3/3] doc: regenerate regexprops.texi https://cgit.git.sv.gnu.org/cgit/findutils.git/commit

Re: regexprops-generic propagation

Bernhard Voelker wrote: > * [PATCH 2/3] regexprops: sort regex_map alphabetically >https://cgit.git.sv.gnu.org/cgit/findutils.git/commit/?id=c9c2c511759 > > * [PATCH 3/3] doc: regenerate regexprops.texi >https://cgit.git.sv.gnu.org/cgit/findutils.git/commit/?id=facc27e1804 > > 2. Commit (

Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

On 2025-07-09 17:38, Collin Funk wrote: I assume it will have to wait until the next release. Yes, at least until then.

Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

On 7/10/25 02:38, Collin Funk wrote: Bernhard Voelker writes: 2. Commit (to be pushed) to gnulib - see attachment. Good to push? That patch looks good, thanks. I confirmed that I receive the same output when running './regexprops "Regular Expressions" generic'. Thanks for the review, push

Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

Bernhard Voelker writes: > 2. Commit (to be pushed) to gnulib - see attachment. > > Good to push? That patch looks good, thanks. I confirmed that I receive the same output when running './regexprops "Regular Expressions" generic'. I'll send you a patch later to fix 'make syntax-check' after the

Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

neric: update from regex.h * doc/regexprops-generic.texi: Re-generate by running the 'regexprops' binary from GNU findutils: ./regexprops "Regular Expressions" generic At least the recent(ish) change (efd5c380ff) to regex.h aligning gnulib with Emacs behavior had made this documen

Re: Error report: There is an error in the manual of findutilis

On 7/7/25 10:46, zhaiyn wrote: Because I do not have the ability to write in English, the following content is in Chinese. Sorry! 出现错误的内容链接: https://www.gnu.org/software/findutils/manual/html_node/find_html/Finding-the-Shallowest-Instance.html ; 在该文中，示例代码是这样写的:   find repo/ \   -exec test -

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

Re: [PATCH] find: add option -fail_exec

On 5/21/25 19:24, Tavian Barnes wrote: On Wed, May 21, 2025 at 1:51 AM Bernhard Voelker wrote: [snip] Although I like in general the idea to have more control over exit values in the caller, I have the suspicion that mapping to EXIT_FAILURE may be too simple: How to distinguish that from other

Re: [PATCH] find: add option -fail_exec

On Wed, May 21, 2025 at 1:51 AM Bernhard Voelker wrote: > [snip] > Although I like in general the idea to have more control over > exit values in the caller, I have the suspicion that mapping to > EXIT_FAILURE may be too simple: > > How to distinguish that from other find(1) errors? > In your case

Re: [PATCH] find: add option -fail_exec

On 5/20/25 22:56, Bernhard Voelker wrote: > So would you please describe further your use cases with some > examples? P.S. It makes sense looking over the fence as well: does one of the other find(1) implementations have such a feature already, and how is it solved there? Thanks & have a nice da

Re: [PATCH] find: add option -fail_exec

On 5/3/25 17:07, Tomas Mudrunka wrote: When find -exec is used in build scripts, ci pipelines and similar, it's good to have way to ensure that failed subprocess executed by find results in non zero return code of find as whole. Thanks for the suggestion and the patch. Previously this was onl

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

On 4/25/22 05:39, raf wrote: 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. Thanks - phew, time flies! Meanwhile, the translators have s

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

On 3/15/25 10:30, James Youngman wrote: I don't think anybody ever intended to support things like -). But we don't have visibility into what people are actually doing. I'd suggest issuing a warning for these usages. [edit] So that we have the option to eventually make them an error. Fair en

Re: find.1: Some remarks and a patch with editorial changes for this man page

Hi Bjarni, On 3/8/25 16:50, Bjarni Ingi Gislason wrote: * What led up to the situation? Checking for defects with a new version test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z < "man page" [Use "groff -e ' $' -e '\\~$' " to find obvious trailing spaces.]

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

On 3/23/25 23:45, Bernhard Voelker wrote: > Pushing soon. Pushed at: https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=dc3365628e24c Have a nice day, Berny

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

On 3/14/25 22:45, raf wrote: On Fri, Mar 14, 2025 at 09:11:01AM +0100, Bernhard Voelker wrote: What worries me more is the use of the extra dash '-' for the logical elements '-)' and '-!'. What exactly needs to be fixed? Find should not allow things like '-!'. Why is accepting a - pref

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

[this is a duplicate mail, because initially by mistake I replied just to Bernhard] I don't think anybody ever intended to support things like -). But we don't have visibility into what people are actually doing. I'd suggest issuing a warning for these usages. [edit] So that we have the option

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

On Fri, Mar 14, 2025 at 09:11:01AM +0100, Bernhard Voelker wrote: > On 3/13/25 18:45, Bernhard Voelker wrote: > > $ find "-)" "," "-!" "-ls" > > find: invalid expression: expected expression before closing parentheses > > '-)'. > > This one seems to have been fixed with this commit: > https:

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

On 3/13/25 18:45, Bernhard Voelker wrote: $ find "-)" "," "-!" "-ls" find: invalid expression: expected expression before closing parentheses '-)'. This one seems to have been fixed with this commit: https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=a5659a42fa2db What worries me mor

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

On 3/13/25 05:46, 김민종 wrote: Hi, I'm using findutils-4.7.0 in Ubuntu. While using this program, I found that certain CLI commands caused the system to crash, as shown below: $./find "-)" "," "-!" "-ls" Segmentation fault $ find --version | sed 1q find (GNU findutils) 4.10.0+git.42.faa13013 $

Re: Using .ignore file in find

add support for specific ignore formats to find(1). Eventually a --exclude-from=FILE in the style of grep(1) to filter globbing patterns may make sense. Re. this one: > # list all ignored files This seems to be feasible with: $ find | git check-ignore --stdin One can feed that into another

Re: find terminated with SIGSEGV in partial_quotearg_n

On 2/7/25 08:29, Dietmar Hahn (Fujitsu) wrote: From: Bernhard Voelker , sent: Sunday, January 26, 2025 6:26 PM https://git.sv.gnu.org/cgit/findutils.git/commit/?id=e5d6eb919b9 I couldn't reproduce the issue here, so maybe you could check? Yes, but couldn't reproduce. no worries. I've seen

RE: find terminated with SIGSEGV in partial_quotearg_n

> From: Bernhard Voelker , sent: Sunday, January 26, > 2025 6:26 PM > On 1/24/25 16:03, Dietmar Hahn (Fujitsu) via Bug reports for the GNU find > utilities wrote: > >> From: Bernhard Voelker January 23, 2025 10:49 PM: > >>> The fts_cycle looks corrupted. > >> > >> The underlying gnulib code seem

Re: find terminated with SIGSEGV in partial_quotearg_n

On 1/26/25 9:29 PM, James Youngman wrote: error (0, 0, _("File system loop detected; " "the following directory is part of the cycle: %s"), safely_quote_err_filename (0, ent->fts_path)); Would it be clearer to stick to just saying "cycle" or "loop" but not using both words? I'm just

Re: find terminated with SIGSEGV in partial_quotearg_n

error (0, 0, _("File system loop detected; " "the following directory is part of the cycle: %s"), safely_quote_err_filename (0, ent->fts_path)); Would it be clearer to stick to just saying "cycle" or "loop" but not using both words? I'm just considering that we may be making it harder to

Re: tests: adjust shell syntax that breaks AIX /bin/sh

FWIW, I think AIX is compliant here.I believe that this syntax is valid: for x; do y; done ... and this syntax is also valid for x do y done ... but for x; do y done ... isn't (at least in some POSIX versions - I don't know if this changed at any point).

Re: tests: adjust shell syntax that breaks AIX /bin/sh

On 1/26/25 07:29, Collin Funk wrote: On AIX, /bin/sh causes a testsuite failure with an output like this: Running /home/collinfunk/findutils-4.10.0.40-d4417/find/testsuite/find.gnu/execdir-multiple.exp ... FAIL: execdir-multiple.new-O0, ./runme[6]: syntax error at line 7 : `newline

Re: find terminated with SIGSEGV in partial_quotearg_n

On 1/24/25 16:03, Dietmar Hahn (Fujitsu) via Bug reports for the GNU find utilities wrote: From: Bernhard Voelker The fts_cycle looks corrupted. The underlying gnulib code seems to be a bit vague about this, and the comment about coreutils is also not true (any more): https://git.savannah.gnu

RE: find terminated with SIGSEGV in partial_quotearg_n

Hi Bernhard, > From: Bernhard Voelker 2025 10:49 PM: > > Hi Dietmar, > > On 1/22/25 15:47, Dietmar Hahn (Fujitsu) via Bug reports for the GNU find > utilities wrote: > > Hi list, > > > > I have 2 core files from the find command. > > It's findutils-4.8.0-1.20 from SuSE SLES15SP5. > > thanks fo

Re: find terminated with SIGSEGV in partial_quotearg_n

Hi Dietmar, On 1/22/25 15:47, Dietmar Hahn (Fujitsu) via Bug reports for the GNU find utilities wrote: Hi list, I have 2 core files from the find command. It's findutils-4.8.0-1.20 from SuSE SLES15SP5. thanks for the bug report. Core was generated by `find -type f -name *xx* -empty -delete

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

almost trivial, as the implementation > > has > > just to evaluate the already known value of 'struct stat' member 'rdev', and > > we > > already deal with major/minor numbers in -ls,-fls (although not in -printf). > > > > I also don&#x

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

r 'rdev', and > we > already deal with major/minor numbers in -ls,-fls (although not in -printf). > > I also don't see that this would add much risks or bloat, so it may fit quite > well into find(1). > As such, I'm hereby re-opening this one for discussion. >

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 practical example why it would be dangerous. > > > > [...] > >

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

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 practical example why it would be dangerous. > > [...] > > > Second, my main point, is that I believe that there is confusion > > a

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

On 12/15/24 20:47, Bernhard Voelker wrote: `xargs -0` is similar to many tools allowing Zero-delimited input. And often the last entry of input does not have to be Zero-terminated. Here some examples from the GNU coreutils. * `sort -z`: * `uniq -z`: * `cut -z` * `tail -z`: P.S. I forgot to men

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

Hi Chris, On 12/14/24 19:55, Christoph Anton Mitterer wrote: On Fri, 2024-12-13 at 23:05 +0100, Bernhard Voelker wrote: I never saw a practical example why it would be dangerous. Well it seems to me, that in that case even a 1 in Million chance might have too catastrophic consequences to wait

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

Hey. On Fri, 2024-12-13 at 23:05 +0100, Bernhard Voelker wrote: > I never saw a practical example why it would be dangerous. Well it seems to me, that in that case even a 1 in Million chance might have too catastrophic consequences to wait for it happening in the wild. Again, consider the find

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

Hi Christoph, On 12/12/24 4:17 PM, Christoph Anton Mitterer wrote: So I'd still ask you to consider whether GNU's xargs can be modified accordingly (and not just in some POSIXLY_CORRECT mode), as any other behaviour seems truly dangerous to me. I never saw a practical example why it would be d

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

Hey Bernhard. An update on this: POSIX guys pointed me to: https://austingroupbugs.net/view.php?id=1872#c6956 That will still leave it as "allowed" for an implementation to take a final non-terminated "line" as input, but still recommends against doing so and still indicates the future direction

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

On Mon, 2024-12-09 at 21:00 +0100, Bernhard Voelker wrote: > The above test case can be simplified to the cases: > >    $ printf 'hello' | xargs -0 printf "<%s>\n" >    > >    $ printf 'hello\0' | xargs -0 printf "<%s>\n" >    > >    $ printf 'hello\0world' | xargs -0 printf "<%s>\n" >    >  

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

On 12/9/24 03:34, Christoph Anton Mitterer wrote: Hey. Not sure whether this has been brought up before (at least a quick search didn't reveal anything in the bug tracker or the archive). xargs -0 still executes the command even when no terminating NUL has been found in the (last) line. As sho

Re: maint: don't use gettimeofday

On 8/2/24 06:46, Collin Funk wrote: Patch attached. Thanks, now as the Copyright paperwork is done, I pushed both: * maint: don't use gettimeofday https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=5db475b30607242227571a97355339392274abfc * maint: update Makefile variables used by

Re: [bug #66365] find -exec treats + as special when it shouldn't

On 11/2/24 19:47, James Youngman wrote: I have installed a modified version of the patch (1dcdf3de8e27cc130968891ee5a529a461a248da), updated in the ways you suggested. Thanks, nice. I have the 4 attached follow-up patches. Pushing soon. Have a nice day, BernyFrom 57fb016b73c2df6ab5e4cc908f716

Re: [bug #66365] find -exec treats + as special when it shouldn't

I have installed a modified version of the patch (1dcdf3de8e27cc130968891ee5a529a461a248da), updated in the ways you suggested. On Sat, Nov 2, 2024 at 9:24 AM Bernhard Voelker wrote: > > Hi James, > > thanks, technically this patch fixes it, yet I think it deserves some more > love before pushin

Re: [bug #66365] find -exec treats + as special when it shouldn't

Hi James, thanks, technically this patch fixes it, yet I think it deserves some more love before pushing. First of all, this patch does not cleanly apply. $ git am /tmp/x.patch Applying: Fix Savannah bug 66365. error: git diff header lacks filename information when removing 1 leading pa

Re: [bug #66365] find -exec treats + as special when it shouldn't

>From e7641882e3ef373b6c58bcf27fbc49269e2541f3 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Thu, 31 Oct 2024 15:06:02 + Subject: [PATCH] [find] Fix Savannah bug 66365. A "+" only terminates -exec when it immediately follows an argument which is exactly "{}". --- find/parser.c

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 b > b.txt; echo c

Re: Re: xargs mock run

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 b > b.txt; echo c > "c with spaces.txt" $  echo * | xargs echo gzip |

Re: Re: Re: xargs mock run

raf wrote: can't easily read your response because of the formatting and html character encoding I dont know why it happened, apologize. I guess due to pasteing from clipboard. If I write it 'manually' in client it will likely not happen. I think what you are trying to achieve might loo

Re: Re: xargs mock run

On Tue, Oct 08, 2024 at 03:30:22AM +0200, oset wrote: > > On Mon, Oct 07, 2024 at 07:27:24PM +0200, oset > wrote: I would appreciate you to not include > someones email address in a public mail list letter. I have enough > spam, I do not need more. > You can. Just replace the actual

Re: Re: xargs mock run

> On Mon, Oct 07, 2024 at 07:27:24PM +0200, oset wrote:I would appreciate you to not include someones email address in a public mail list letter. I have enough spam, I do not need more. > You can. Just replace the actual command with "sh -c 'echo ACTUAL_COMMAND'". I cannot

Re: xargs mock run

On Mon, Oct 07, 2024 at 07:27:24PM +0200, oset wrote: > Often, when user uses bit more complex syntax with xargs (or find -exec, for > that matter) the command spectacularly fails, and they dont know why. It > would be beneficial to be able to mock run a command - just print what is to > be

Re: new module 'hasmntopt'

On 10/7/24 18:58, Bruno Haible wrote: Either remove that #include (since fstype.c does not need it, AFAICS), or make it unconditional. Good point, thanks. Indeed. Thanks for the report. This patch fixes it: Thanks! Have a nice day, Berny

Re: new module 'hasmntopt'

Hi Berny, > While trying to update gnulib in findutils, I've been prompted by this new > syntax-check failure: > >find/fstype.c:30:#if HAVE_MNTENT_H >maint.mk: do not test the above HAVE__H symbol(s); > with the corresponding gnulib module, they are always true >make: *** [maint

Re: new module 'hasmntopt'

On 8/19/24 5:23 PM, Bruno Haible wrote: 2024-08-19 Bruno Haible ... hasmntopt: New module. ... 2024-08-19 Bruno Haible mntent: New module. While trying to update gnulib in findutils, I've been prompted by this new syntax-check failure: find/fstype.c:30:#if HAVE_M

Re: [PATCH] find: add bison as a requirement for compiling

On 9/17/24 04:47, Dave wrote: Thanks for the tweak, lgtm. Thanks, pushed at: https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=07bd7fa675e Have a nice day, Berny

Re: [PATCH] find: add bison as a requirement for compiling

Hi Berny, Thanks for the tweak, lgtm. -Dave On Tue, Sep 17, 2024 at 1:40 AM Bernhard Voelker wrote: > > Hi Dave, > > On 9/13/24 10:12, Dave wrote: > > From 2a83f217df3469eec4226255ab9d27251dd8f2ba Mon Sep 17 00:00:00 2001 > > From: Dave > > Date: Fri, 13 Sep 2024 07:53:31 + > > Subject: [

Re: [PATCH] find: add bison as a requirement for compiling

Hi Dave, On 9/13/24 10:12, Dave wrote: From 2a83f217df3469eec4226255ab9d27251dd8f2ba Mon Sep 17 00:00:00 2001 From: Dave Date: Fri, 13 Sep 2024 07:53:31 + Subject: [PATCH] find: add bison as a requirement for compiling *README-hacking(prerequisites): Compiling without bison would result i

Re: [PATCH] find: add bison as a requirement for compiling

>From 2a83f217df3469eec4226255ab9d27251dd8f2ba Mon Sep 17 00:00:00 2001 From: Dave Date: Fri, 13 Sep 2024 07:53:31 + Subject: [PATCH] find: add bison as a requirement for compiling *README-hacking(prerequisites): Compiling without bison would result in `fatal error: parse-datetime.c: No such

Re: Feature Requests for find and date

[moving from coreut...@gnu.org [1] to here] [1] https://lists.gnu.org/r/coreutils/2024-08/msg8.html On 8/19/24 14:10, Pádraig Brady wrote: On 18/08/2024 00:47, Marc Gutt wrote: Dear GNU Team, I like to see the following features / enhancements: find Add %z to help / man page. The numeric

Re: find omits dollar signs in filenames was wrong

Oh sorry, that was BS: It is "ls -q" which inserts dollar signs in front of quoted formatting characters. -- Cheers, Olf On 21 July 2024 19:16:11 CEST, Olf wrote: >Hi, > >the GNU find utility does not output dollar signs embedded in >filenames, i.e. it emits non-matching filenames! I am pre

Re: test-framework-sh: Fix typo in function invocation (regression 2024-06-11).

Bernhard Voelker writes: > Some of the files have to be physically copied into the version control like > COPYING > and the 'fdl.texi', for other files we wanted to keep track of changes. > This is the same in coreutils. > > Hence, the change in tests/init.sh will come with the next gnulib updat

Re: test-framework-sh: Fix typo in function invocation (regression 2024-06-11).

[+findutils ML] Hi Colin, On 6/24/24 9:00 AM, Collin Funk wrote: Hi Bernhard, Bernhard Voelker writes: thanks for the heads-up, but findutils doesn't have 5c2e65d9c760 (June 12), but is on the older commit 623bcc22f474 from (May 27); hence the bug is/was not yet there. :-) Sorry, my expla

Re: test-framework-sh: Fix typo in function invocation (regression 2024-06-11).

[FWing to findutils ML] On 6/24/24 2:55 PM, Bernhard Voelker wrote: Hi Collin, On 6/24/24 9:43 AM, Collin Funk wrote: Hi Bernhard, I said: gmake  tests/xargs/test-sigusr gmake[2]: Entering directory '/home/collin/.local/src/findutils'    CC   tests/xargs/test-sigusr.o tests/xargs/test-s

Re: MinGW support

It appears you've been busy since. I've rebased 'mingw' onto master again, taking care to remove all tabs (and trailing whitespaces). I've also added 'mingw-4.10.0' which is based on the v4.10.0 tag.

Re: findutils 4.9.0: localeconv test failed on RISCV

Hello, There's been some char-related changes in the related gnulib files between findutils 4.9.0 (2022) and the new 4.10.0. Would you please test if that problem still exists there? I tried findutils 4.10.0. The problem still exists. Yuqi can you please tell me what operating system / libc

Re: findutils 4.9.0: localeconv test failed on RISCV

Hi, Bernhard Voelker writes: > There's been some char-related changes in the related gnulib files between > findutils 4.9.0 (2022) and the new 4.10.0. > Would you please test if that problem still exists there? No harm in trying this. However, I feel like this might be a platform bug. Yuqi can

Re: findutils 4.9.0: localeconv test failed on RISCV

On 6/6/24 11:01, Yuqi Guo wrote: File:     gnulib-tests/test-localeconv.c Code: ``` struct lconv *l = localeconv (); ASSERT (l->frac_digits == CHAR_MAX); ASSERT (l->p_cs_precedes == CHAR_MAX); ASSERT (l->p_sign_posn == CHAR_MAX); ASSERT (l->p_sep_by_space == CHAR_MAX); ASSERT (l->n_cs_prec

Re: [bug #65812] make dist includes bnary file

On 5/30/24 21:27, James Youngman wrote: Fixed in git, with attached patch. <https://savannah.gnu.org/bugs/?65812> Thanks. This introduced a syntax-check failure. Fixed with the attached 2 commits. * [PATCH 1/2] maint: improve ERE in sc_tests_list_consistency * [PATCH 2/2] tes

Re: [bug #63605] Large number of UBSAN failures in test suite

James Youngman writes: > Fixed with the attached patch. > Thank you!

Re: [bug #63605] Large number of UBSAN failures in test suite

Fixed with the attached patch. On Sun, May 19, 2024 at 10:26 PM James Youngman wrote: > Update of bug #63605 (group findutils): > > Status:None => Fixed > > Assigned to:None => jay > > > _

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

Documentation update for the above change. On Sun, May 19, 2024 at 11:18 AM James Youngman wrote: > This patch addresses the POSIX compliance aspect explained by Geoff > Clare. A test is included. > > > From 9fed05088f5bfe5d7d7b5e92ae301517e84760f8 Mon Sep 17 00:00:00 2001 From: James Youngma

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

This patch addresses the POSIX compliance aspect explained by Geoff Clare. A test is included. From b560e3f911c1eb0095a2c07a461bc28f7335fbd1 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Sun, 19 May 2024 11:05:38 +0100 Subject: [PATCH] [xargs] POSIX requires SIGUSR1/2 to be fatal if not bloc

Re: [bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

Fixed in git with the attached patch. On Thu, Jul 20, 2023 at 8:46 AM anonymous wrote: > URL: > > > Summary: Unexpected behaviour of xargs when multiple > children > exit with 255 in parallel >Group: findutils >

Re: MinGW support

> This repo is a fork of jamesyoungman/findutils:master but that is a > (frequently very out of date) mirror of the real findutils git repository, > which is on Savannah, not github (see > https://savannah.gnu.org/git/?group=findutils for details). > > If you'd like to discuss next steps, the fi

Re: [bug #65283] Misleading statement, I believe

Fixed with this patch. On Fri, May 17, 2024 at 9:49 AM James Youngman wrote: > Update of bug #65283 (group findutils): > > Severity: 3 - Normal => 2 - Minor > > Status:None => Fixed > > Assigned to:

Re: [bug #65297] -regexp incompatible statements concerning default

Fixed with this patch. On Fri, May 17, 2024 at 9:31 AM James Youngman wrote: > Update of bug #65297 (group findutils): > > Status:None => Fixed > > > ___ > > Follow-up Comment #2: > > Fixed in git. > >

Re: MinGW support

On Thu, May 9, 2024 at 11:46 AM Cyril Arnould wrote: > Hi! I was wondering if there's a possibilty for GNU findutils to > officially start supporting MinGW-w64. To set your expectations, this email isn't going to answer that question. > It has been ported before as > part of both the GnuWin32

Re: [bug #65305] @var{name} should be @var{NAME}

I pushed the attached simple patch to fix this. From e549900aa62dde81c65af5ede950a7918a0facb5 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Fri, 17 May 2024 08:42:07 +0100 Subject: [PATCH] [doc] Use @var{name}, not NAME or @var{NAME} in "Hard Links". To: findutils-patc...@gnu.org The @var{n

Re: [PATCH 0/2] gnulib related patches

Looks good. I'm a fan of ght gnulib-tool rewrite.

Re: Rust findutils

On Wed, May 15, 2024 at 6:53 PM James Youngman wrote: > > [I changed the subject line because this is quite a tangent from the original > thread] > > On Wed, May 15, 2024 at 7:50 PM Nikolaos Chatzikonstantinou > wrote: >> >> >> How about GNU does a call to arms for an alternative Rust >> implem

Re: Rust findutils

I wrote: > The advantage of using gnulib for things like fts is that findutils is not the only consumer, and we're very likely to notice issues with it even in weird corner cases. I should explain that this advantage is strong enough that, following a multi-year period of parallel running, we rep

Re: Ensuring that all the fields of struct predicate are initialized

On Tue, May 14, 2024 at 5:16 PM James Youngman wrote: > One of the worries in the back of my mind with findutils has always been > about whether all the fields in `struct predicate` actually get initialised > correctly by the parser functions. > > I should explain that recently I've been using oth

Re: Ensuring that all the fields of struct predicate are initialized

e variety of utility functions around predicates which already exist: get_new_pred_chk_op, get_new_pred_noarg, insert_primary_withpred, insert_primary, collect_arg_nonconst, ... I would see some potential to make the code better readable. Compared to other find(1) implementations, the GNU code is really com

Re: Ensuring that all the fields of struct predicate are initialized

On 5/14/24 2:15 PM, James Youngman wrote: > I should explain that recently I've been using other languages which make > it possible to ensure at compile time that things are correctly initialised > and consistently used, and to be direct about it, I miss these things in C. Newer GCC versions have

Re: Some tidy-ups

On 5/14/24 10:06 AM, James Youngman wrote: See attached patches. If no objections, I will submit these soon. all 3 look good to me, thanks! Have a nice day, Berny

Re: Some tidy-ups

On Tue, May 14, 2024 at 9:06 AM James Youngman wrote: > > > On Tue, May 14, 2024 at 9:06 AM James Youngman wrote: > >> See attached patches. If no objections, I will submit these soon. >> >> >> From 76215fb45f29a035ddeb64ede8eb8078f02f5e75 Mon Sep 17 00:00:00 2001 From: James Youngman Date: M

Re: Some tidy-ups

On Tue, May 14, 2024 at 9:06 AM James Youngman wrote: > See attached patches. If no objections, I will submit these soon. > > > From ab0137eff33dcb09b1d108d99e3549fb1e5d38a6 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Mon, 13 May 2024 21:37:05 +0100 Subject: [PATCH 2/3] Rename is_fts_e

Re: Enhancement request for 'locate'

On 4/22/24 23:18, James Youngman wrote: locate-ls() { locate -0 "$@" | xargs -0 ls -ld } I'd suggest using -r there also, so that if no files are found, the user doesn't get a surprising listing of just "." (with its mod-time and so forth). $ xargs --help | grep empty -r, --no-run-if-e

Re: Enhancement request for 'locate'

> > > > locate-ls() { >locate -0 "$@" | xargs -0 ls -ld > } > > I'd suggest using -r there also, so that if no files are found, the user doesn't get a surprising listing of just "." (with its mod-time and so forth).

Re: Enhancement request for 'locate'

Hi Seamus, On 2/13/24 22:02, Seamus de Mora wrote: Hello, I have a request for the 'locate' program: thanks. I would like to see an option added that would add the modification time/date to the results (files found by locate). This would be similar (even identical) to the output of 'ls -l '

Re: [bug #65386] unknown predicate error when using '-1M' as lt 1

You need a space after -size. On Thu 29 Feb 2024, 03:59 anonymous, wrote: > URL: > > > Summary: unknown predicate error when using '-1M' as lt 1 >Group: findutils >Submitter: None >Submi

Re: Null pointer dereference

On 2/9/24 19:13, John Seth Thielemann wrote: > Building with a gcc nolibc / musl / linux setup found a null pointer dereference in the pred_and handling. > > Take care, > J. Seth Thielemann Thanks for the patch, but ... > diff -Naur /musl/opt/findutils-4.9.0/build/findutils-4.9.0.pristine/find/

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 is not existed and > > find co

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

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 is not > existed and find command not says that file is not fo

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

I can't reproduce this claimed problem with findutils 4.9.0: horizon:~$ find foo find: ‘foo’: No such file or directory horizon:~$ echo $? 1 horizon:~$

  1   2   3   4   5   6   7   8   9   10   >