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: 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: 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: [bug #66365] find -exec treats + as special when it shouldn't

h failed at 0001 Fix Savannah bug 66365. >... > > Didn't you use 'git format-patch -1' and 'git send-email ...'? > > On 10/31/24 17:28, James Youngman wrote: > > From e7641882e3ef373b6c58bcf27fbc49269e2541f3 Mon Sep 17 00:00:00 2001 > > From: James Young

[PATCH] find: -exec is terminated by + only if the prior arg is exactly '{}'

A "+" only terminates -exec when it immediately follows an argument which is exactly "{}" (and not, for example, "{}x"). This fixes Savannah bug 66365. * NEWS: explain this change. * doc/find.texi: update one place which omitted the '{}' before '+'. * find/parser.c (insert_exec_ok): consider + to

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

Follow-up Comment #2, bug #66365 (group findutils): Because GNU find currently rejects these commands with the error shown in Geoff's comment, I'm not expecting there to be a substantial problem with backward incompatibility. That is, I doubt that anybody is likely to be relying on GNU find rejec

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

Follow-up Comment #4, bug #66365 (group findutils): I think the attached patch should fix this. (file #56587) ___ Additional Item Attachment: File name: 0001-find-Fix-Savannah-bug-66365.patch Size: 4KiB

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 "{}&qu

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

Update of bug #66365 (group findutils): Release:None => 4.2.12 ___ Follow-up Comment #3: This bug was introduced in findutils 4.2.12, which is the release which added support for "+".

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

Update of bug #66365 (group findutils): Severity: 3 - Normal => 4 - Important Assigned to:None => jay ___ Reply to this item at:

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

Follow-up Comment #1, bug #66365 (group findutils): Implicit in Geoff's comment is that the rules for terminating the expression are different for the ";" and "+" cases. The full wording from the standard (IEEE Std 1003.1-2024) is: -exec utility_name [argument ...] ; -exec utility_name [argumen

[bug #66135] loop: different error messages describe an identical (?) error

Follow-up Comment #1, bug #66135 (group findutils): In the second case find's traversal is already inside the loop (as the initial "." is part of the loop) while in the first case "." is not part of the loop. I assume this accounts for the difference in error message. ___

[bug #65998] xargs strange behavior

Update of bug #65998 (group findutils): Status:None => Working as Intended Assigned to:None => jay Open/Closed:Open => Closed __

[bug #65895] Expression order matters?

Follow-up Comment #4, bug #65895 (group findutils): The semantics around evaluation order and precedence in find's command line are carefully documented even if they're not obvious or intuitive (the "," operator in particular is unlike other systems). Making changes to invalidate a currently-v

[bug #65895] Expression order matters?

Update of bug #65895 (group findutils): Status:None => Invalid Assigned to:None => jay Open/Closed:Open => Closed __

[bug #65890] xargs keeps child processes in zombie state before starting a new process

Follow-up Comment #1, bug #65890 (group findutils): You didn't state what version of findutils this problem affects. Is this problem reproducible with findutils version 4.10.0? ___ Reply to this item at:

[bug #65831] Test -type l is unsuccessful for symlink loops

k: Any Fixed Release: None ___ Follow-up Comments: --- Date: Mon 03 Jun 2024 12:55:32 PM UTC By: James Youngman >From https://savannah.gnu.org/bugs/?51926#comment8 >Co

[patch] Process find's leading options in a POSIX-compliant way

This patch makes find accept things like "find -PP .". From c10a0126dd56e42a8118494cf67a6c74eb58c0db Mon Sep 17 00:00:00 2001 From: James Youngman Date: Mon, 3 Jun 2024 08:44:12 +0100 Subject: [PATCH] find: Process -P -H -L options in a POSIX-compliant way. To: findutils-patc...@gnu.or

[bug #38474] Unintended (?) behaviour change of -perm +mode predicate

Update of bug #38474 (group findutils): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #13: I don't think ther

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

Follow-up Comment #6, bug #42501 (group findutils): Chris, could you please determine which releases of FreeBSD and Mac OS X introduced this option? I would like to mention this in the sections of the documentation which deal with compatibility.

Implement new -E option for FreeBSD, Mac OS X compatibility

See attached patch (which I haven't pushed). This "fixes" the feature request https://savannah.gnu.org/bugs/index.php?42501 From 6b144b8c4d8199310ee07094ef70e7f597891bc5 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Sun, 2 Jun 2024 10:34:59 +0100 Subject: [PATCH] Add -E op

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

Update of bug #42501 (group findutils): Status:None => Code Review ___ Follow-up Comment #5: This option is implemented by the attached patch. I haven't pushed this patch yet. (file #561

[bug #57461] Configure leaves directory trees that cannot be removed on PowerPC Mac OS X 10.5.8, Leopard

Follow-up Comment #7, bug #57461 (group findutils): Try running configure with this question "pre-answered": env gl_cv_func_getcwd_path_max=no ./configure This should result in a config.h file which says: /* #undef HAVE_MINIMALLY_WORKING_GETCWD */ __

[bug #56823] -regextype egrep compatibility issue, requires full string match as opposed to egrep

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

[bug #43507] find fails on -exec, -execdir, -ok, -okdir

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

Pushed tabs-to-spaces change

I pushed the change converting tabs in Findutils C source to spaces. The git branch containing this change is now deleted (since it has been merged). https://www.youtube.com/watch?v=SsoOG6ZeyUI

[bug #65812] make dist includes bnary file

Update of bug #65812 (group findutils): Status:None => Fixed Fixed Release:None => 4.10.0 ___ Follow-up Comment #1: Fixed in git, with

[bug #65812] make dist includes bnary file

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

[bug #65804] ~/bin detected as relative path

Follow-up Comment #3, bug #65804 (group findutils): Tilde-expansions can also expand to values relative to the current directory and (worse) $OLDPWD and this is precisely the dangerous scenario that the warning is concerned with. Note the second paragraph in this excerpt from the manual page for

[bug #65804] ~/bin detected as relative path

Follow-up Comment #2, bug #65804 (group findutils): It does appear that Bash performs tilde expansion on $PATH entries while execvp (whicvh is what the env program uses) does not: $ env -u ENV -u BASH_ENV PATH='/bin:~/bin' bash --norc -c 'type rebuild-findutils.sh' rebuild-findutils.sh is /home/

Optimization/optimisation

My earlier patch missed a few cases. The attached patch cleans those up. This change is probably too large to be included in findutils 4.10.0 at this point. James. From 3f0f5f8f485b5ca89075f63c2dd9986a74b54df5 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Mon, 27 May 2024 22:10:45 +0100

[bug #58427] Cost-base optimiser breaks short-circuit evaluation

Update of bug #58427 (group findutils): Status: In Progress => Fixed ___ Follow-up Comment #4: The attached patch (which I have pushed) disables CBO by default. (file #56107) This problem i

[bug #63765] Unexpected deletions : find warnings with missing selection (true bug or half way between bug and non-bug ?)

Follow-up Comment #4, bug #63765 (group findutils): That would be a backward-incompatible change. ___ Reply to this item at: ___ Message sent via Savann

[bug #51926] -xtype l fails on symbolic links that have a loop

Update of bug #51926 (group findutils): Status:None => Fixed ___ Follow-up Comment #7: This problem is fixed in the git code for findutils. To resolve your problem, you could either w

[bug #22467] updatedb: --prunepaths doesn't allow directories with whitespace

Update of bug #22467 (group findutils): Status:None => Duplicate Assigned to:None => jay Open/Closed:Open => Closed __

[bug #63461] Typo in pt_BR.po

Update of bug #63461 (group findutils): Status: In Progress => Fixed ___ Reply to this item at: ___ Mess

[bug #65794] Automake warnings for tests/xargs/test-sigusr.c

Update of bug #65794 (group findutils): Status:None => Fixed ___ Follow-up Comment #1: This problem is fixed in the git code for findutils. To resolve your problem, you could either w

[bug #65796] tests/misc/help-version.sh fails distcheck when tree is dirty

Follow-up Comment #1, bug #65796 (group findutils): The improved diagnostic is in patch 64e9ddbd8cdbe1f9e93e637d28595c2ef5174bf6 ___ Reply to this item at:

[bug #65796] tests/misc/help-version.sh fails distcheck when tree is dirty

: None Severity: 4 - Important Item Group: Test suite failure Status: None Privacy: Public Assigned to: berny Originator Name: James Youngman Originator Email: Open/Closed: Open R

[bug #58156] Order of xargs -L and -I flags matters

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

[bug #26945] [wishlist] locate-d: dynamic updates using dnotify, inotify or fsnotify

Update of bug #26945 (group findutils): Status: Postponed => None ___ Reply to this item at: ___ Mess

[bug #22715] find command for NETPATHS in updatedb is inconsistent with that for SEARCHPATHS

Update of bug #22715 (group findutils): Status: Postponed => None ___ Reply to this item at: ___ Mess

[bug #22467] updatedb: --prunepaths doesn't allow directories with whitespace

Update of bug #22467 (group findutils): Status: Postponed => None ___ Reply to this item at: ___ Mess

[bug #20510] [wishlist] updatedb does not use gettext

Update of bug #20510 (group findutils): Status: Postponed => None ___ Reply to this item at: ___ Mess

[bug #19485] feature request: storing relative pathnames in locate databases

Update of bug #19485 (group findutils): Status: Postponed => None ___ Reply to this item at: ___ Mess

[bug #19374] Insufficient quoting of PRUNEPATHS in updatedb

Update of bug #19374 (group findutils): Status: Postponed => None ___ Reply to this item at: ___ Mess

[bug #17410] [wishlist] updatedb flexibility/doc

Update of bug #17410 (group findutils): Status: Postponed => None ___ Reply to this item at: ___ Mess

[bug #8599] updatedb / locate is unusable over NFS

Update of bug #8599 (group findutils): Status: Postponed => None ___ Reply to this item at: ___ Messag

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

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

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

Follow-up Comment #2, bug #65386 (group findutils): Also the list of starting points needs to be given before the tests and actions. That is, find recup_dir.101 -type f -a -size -1M rather than find . -type f -a -size -1M recup_dir.101 __

[bug #63765] Unexpected deletions : find warnings with missing selection (true bug or half way between bug and non-bug ?)

Update of bug #63765 (group findutils): Open/Closed:Open => Closed ___ Follow-up Comment #2: Marked as WAI for a year, time to close this I think.

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

Update of bug #56410 (group findutils): Status: Working as Intended => None ___ Follow-up Comment #18: Since a documentation update is needed (prior comments point this out), this issue cannot be "W

[bug #56832] FAIL: tests/misc/help-version

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

[bug #52558] find does not print symlink object in case of follow symbolic links

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

[bug #15037] [Wishlist] find -ls isn't flexible enough but can't be emulated via -printf

Update of bug #15037 (group findutils): Status:None => Obsolete Open/Closed:Open => Closed ___ Follow-up Comment #4: ~19y since the last

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

Follow-up Comment #3, bug #64857 (group findutils): Siegfried, if you don't respond, this bug will be marked obsolete and closed. ___ Reply to this item at: ___

[bug #62255] find -iname *Word* and find -iname *word* give different results

Update of bug #62255 (group findutils): Status: Need Info => Obsolete Open/Closed:Open => Closed ___ Follow-up Comment #5: No response from su

[bug #48298] Find performance problem on simple conditions/large directories

Update of bug #48298 (group findutils): Status: Need Info => Obsolete Open/Closed:Open => Closed ___ Follow-up Comment #2: No response in 4y,

[bug #46815] problem when testing file size

Update of bug #46815 (group findutils): Status: Need Info => None ___ Reply to this item at: ___ Mess

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

Update of bug #46791 (group findutils): Status: Need Info => Obsolete Open/Closed:Open => Closed ___ Follow-up Comment #2: No response in 7y,

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

Update of bug #42501 (group findutils): Status: Need Info => None ___ Reply to this item at: ___ Mess

[bug #39897] [RFE] Add "--max-count" feature to find

Update of bug #39897 (group findutils): Status: Need Info => Obsolete Open/Closed:Open => Closed ___ Follow-up Comment #2: No response in ~8y,

[bug #35254] Compress sort's temporary files

Update of bug #35254 (group findutils): Status: Need Info => None ___ Reply to this item at: ___ Mess

[bug #26641] Wrong directory hard link count message on automounted directory.

Update of bug #26641 (group findutils): Status: Need Info => None ___ Reply to this item at: ___ Mess

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

Follow-up Comment #2, bug #40577 (group findutils): I marked bug#27558 as a duplicate of this one. ___ Reply to this item at: ___ Message sent via Savan

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

Update of bug #27558 (group findutils): Status: Need Info => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #4: Rolling this up int

[bug #65792] Improve support for file birth time

Follow-up Comment #2, bug #65792 (group findutils): > Perhaps it makes sense to add a function in Gnulib that allows fetching the creation-time of a file? That already exists (https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/stat-time.h#n156) and we're using it, as detailed in the first co

[bug #32976] find has no option to ignore case of starting directories

Update of bug #32976 (group findutils): Status: Need Info => None ___ Reply to this item at: ___ Mess

[bug #37093] /usr/bin/xargs: rm: Argument list too long during make distclean in cross chroot

Update of bug #37093 (group findutils): Status: Need Info => Obsolete Assigned to:None => jay Open/Closed:Open => Closed __

[bug #52129] find lacks "-older" option symmetric to "-newer"

Update of bug #52129 (group findutils): Status: Need Info => Obsolete Assigned to:None => jay Open/Closed:Open => Closed __

[bug #47261] find produces two different results for the same command

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

[bug #65795] Set and meet code coverage standards

k: Any Fixed Release: None ___ Follow-up Comments: --- Date: Sun 26 May 2024 11:40:31 AM UTC By: James Youngman Establish an expectation for code coverage level. Meet it. (James c

[bug #65794] Automake warnings for tests/xargs/test-sigusr.c

n Lock: Any Fixed Release: None ___ Follow-up Comments: --- Date: Sun 26 May 2024 11:24:33 AM UTC By: James Youngman automake: warning: source file 'tests/xargs/test-sigu

[bug #65793] find -ls should match find -dils

Fixed Release: None ___ Follow-up Comments: --- Date: Sun 26 May 2024 11:22:48 AM UTC By: James Youngman find -ls should match the output of ls -dils. However there are some circums

[bug #65792] Improve support for file birth time

n Lock: Any Fixed Release: None ___ Follow-up Comments: --- Date: Sun 26 May 2024 11:09:03 AM UTC By: James Youngman We currently use gnulib's get_stat_birthtime() to determi

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

Update of bug #40577 (group findutils): Summary: find -ls does not display file acl info => ACL support in find (new test(s) and updating -ls) ___ Follow-up Comment #1: find also lacks a test for ACLs, so I modified the su

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

Follow-up Comment #6, bug #58941 (group findutils): By now, probably several find implementations have this or similar features. We should try to avoid introducing gratuitous incompatibilities. That could mean more than one new test could be needed. ___

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

Update of bug #64088 (group findutils): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #3: This is a duplicate

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

Follow-up Comment #5, bug #58941 (group findutils): bug #64088 specifically concerned the attributes append-only, immutable, nodump, fscrypt, verity, dax, projinherit ___ Reply to this item at: __

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

Follow-up Comment #4, bug #58941 (group findutils): bug #64088 is a duplicate of this one. ___ Reply to this item at: ___ Message sent via Savannah http

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

Follow-up Comment #3, bug #58941 (group findutils): bug #49574 is a duplicate of this bug (though that one predates this one). ___ Reply to this item at: __

[bug #65770] Missing support for \(?: (which is part of Emacs regular expressions)

Update of bug #65770 (group findutils): Status:None => Need Info Assigned to:None => jay ___ Follow-up Comment #1: Please report this

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:

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

Update of bug #63605 (group findutils): Status:None => Fixed Assigned to:None => jay ___ Follow-up Comment #1: This problem is fix

[bug #57461] Configure leaves directory trees that cannot be removed on PowerPC Mac OS X 10.5.8, Leopard

Update of bug #57461 (group findutils): Status:Obsolete => Platform Issue Open/Closed: Closed => Open ___ Reply to this item at:

[bug #54745] -mount needs to be slightly different from -xdev

Update of bug #54745 (group findutils): Category:None => find ___ Reply to this item at: ___ Mess

[bug #64816] support ls' --quoting-style= option

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

[bug #64741] Graceful stop of xargs

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

[bug #64605] Add support for extended attributes

Update of bug #64605 (group findutils): Severity: 3 - Normal => 1 - Wish ___ Reply to this item at: ___ Mess

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

Update of bug #64100 (group findutils): Severity: 3 - Normal => 1 - Wish ___ Reply to this item at: ___ Mess

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

Update of bug #64088 (group findutils): Severity: 3 - Normal => 1 - Wish ___ Reply to this item at: ___ Mess

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

Update of bug #63605 (group findutils): Severity: 3 - Normal => 5 - Blocker ___ Reply to this item at: ___ Mess

[bug #63576] Improve find manual with examples and explanations for -size option

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

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

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

[bug #62210] Optional replace-str for the -i option in section 3.2.2.6

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

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

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

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

Update of bug #60207 (group findutils): Severity: 3 - Normal => 4 - Important ___ Reply to this item at: ___ Mess

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

Update of bug #58941 (group findutils): Severity: 3 - Normal => 1 - Wish ___ Reply to this item at: ___ Mess

[bug #58384] incorect documentaion for -regex

Update of bug #58384 (group findutils): Status:None => Fixed Assigned to:None => jay ___ Follow-up Comment #5: Fixed in git a coup

  1   2   3   4   5   6   7   8   9   10   >