[bug #65609] [wishlist] give find a "secure" or "safe" option

Update of bug #65609 (group findutils): Open/Closed:Open => Closed ___ Reply to this item at: ___ Mess

[bug #65609] [wishlist] give find a "secure" or "safe" option

Update of bug #65609 (group findutils): Status:None => Wont Fix ___ Follow-up Comment #3: You can make local changes to the code to achieve what you want. If you think there's a case fo

[bug #64491] Feature request: --exclude-vcs-ignores option in find

Update of bug #64491 (group findutils): Assigned to:None => berny ___ Follow-up Comment #2: Assigning to Bernhard for a second opinion (rather than closing it directly).

[bug #64491] Feature request: --exclude-vcs-ignores option in find

Follow-up Comment #1, bug #64491 (group findutils): I'm not keen on the idea. It will just give rise to requests to add additional complexity for various niche choices of VCS. ___ Reply to this item at:

[bug #65282] Positional option -regextype not mentioned

Update of bug #65282 (group findutils): Status:None => Fixed Assigned to:None => jay ___ Follow-up Comment #1: Fixed in git.

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:

[bug #65283] Misleading statement, I believe

Update of bug #65283 (group findutils): Severity: 3 - Normal => 2 - Minor Status:None => Fixed Assigned to:None => jay __

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. > >

[bug #65297] -regexp incompatible statements concerning default

Update of bug #65297 (group findutils): Status:None => Fixed ___ Follow-up Comment #2: Fixed in git. ___ Reply to this item

[bug #65297] -regexp incompatible statements concerning default

Update of bug #65297 (group findutils): Severity: 3 - Normal => 4 - Important Assigned to:None => jay ___ Follow-up Comment #1: The default is inde

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

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

Update of bug #65305 (group findutils): Status:None => Fixed ___ Follow-up Comment #2: Fixed in git. ___ Reply to this item

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

Update of bug #65305 (group findutils): Severity: 3 - Normal => 2 - Minor ___ Reply to this item at: ___ Mess

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

Follow-up Comment #1, bug #65305 (group findutils): Ordinarily @var{name} and @var{NAME} in body text both render as "NAME" in Info so this kind of inconsistency can be hard to spot. The inconsistency is more obvious in the PDF / Postscript output. ___

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

Update of bug #65305 (group findutils): Assigned to:None => jay ___ Reply to this item at: ___ Mess

Re: [PATCH 0/2] gnulib related patches

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