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

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.

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

URL: Summary: The xargs -r, --no-run-if-empty Option Is Ignored When a Delimiter Is Passed Project: findutils Submitted by: eggert Submitted on: Sat 12 Feb 2022 09:57:51 PM PST Categ

Re: fts: find -xdev, FTS_XDEV and POSIX issue http://austingroupbugs.net/view.php?id=1133

James Youngman wrote: Do the gnulib maintainers feel that the creation of the FTW_MOUNT/FTW_XDEV dichotomy in POSIX nftw() justifies an analogous thing in fts()? Yes, that sounds right.

Re: [bug #33724] Find command is changing the access time of directory

Thanks, I installed that into Gnulib, along with the attached cleanup patch. >From f62317186649b13b32cf636087f6a57a3f3c3805 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 8 Oct 2018 16:53:59 -0700 Subject: [PATCH] fts: cleanup after FTS_NOATIME removal MIME-Version: 1.0 Content-Type: t

Re: [bug #33724] Find command is changing the access time of directory

Bernhard Voelker wrote: So regarding gnulib, there are 2 alternatives: a) rename FTS_NOATIME to FTS_NOATIME, and add a retry to open/openat in each place when that was using O_NOATIME and we got EPERM. I didn't quite get the point of the rename; those two identifiers look identical to me. T

Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'

Barath Aron wrote: Does gnulib support BSD's getmntinfo()? Since it looks not, what can we do? Gnulib ports to the operating systems (including BSD operating systems) available at the time Gnulib was written, and it still ports to the current versions of these operating systems as far as we k

Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'

On 07/16/2018 10:41 PM, Barath Aron wrote: I guess it is more like a hack than a solution. Quite true. We need a real solution here, not a hack. But that will need someone to look into it. If Threos is supposed to be like POSIX, it should use the POSIXish part of the relevant Gnulib code, not

Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'

On 07/16/2018 01:05 PM, Bernhard Voelker wrote: So, my questions are: a) Why the configure use a different type name? Comments suggest that this is what OSF/1 used. b) If it is intentional, then where that type is defined? Presumably in system include files. c) Is this branch of the config

Re: SIGSEGV in partial_quotearg_n()

James Youngman wrote: gnulib foliks, do you have test data which results in FTS_DC being returned by fts_read? If not, have you tested in any other way that ent->fts_cycle->fts_pathlen is in-bounds for this case? The Gnulib tests for fts are minimal and don't use FTS_DC as far as I know. I t

Re: Several changes made to fts.c in Gnulib

The only thing I'd add to that is to suggest using a high value like 0x4000 for FTS_NOLEAF.

Re: Several changes made to fts.c in Gnulib

Kamil Dudka wrote: You even admitted that they could have introduced new bugs. Now you are refusing to push a tiny commit that would significantly help to debug them in environments where only binaries are available. My changes fixed some bugs and did not affect the fts API. Your changes would

Re: Several changes made to fts.c in Gnulib

Kamil Dudka wrote: While I respect your opinion about removing this debugging facility upstream, the -noleaf option stays implemented in Fedora. That shouldn't be a problem. As I mentioned, findutils can still support -noleaf even when using unmodified Gnulib. Just have -noleaf turn off FTS_CW

Re: Several changes made to fts.c in Gnulib

James Youngman wrote: I don't see FTS_CURDIR in fts_.h. Is that the right enum name? Sorry, I meant FTS_CWDFD.

Re: Several changes made to fts.c in Gnulib

Kamil Dudka wrote: Any chance to make the (still documented) -noleaf option of find work again? I'm inclined to agree with Pádraig, in thinking that fts should Just Work without the complexity of an extra option to disable an optimization that is supposed to work. As things stand, 'find' ca

Several changes made to fts.c in Gnulib

I found some subtle bugs in Gnulib fts.c, and created a test case that reliably fails in reiserfs due to confusion with st_nlink. I added this test case to Gnulib and fixed the bugs I found. As far as I can see, the only problems that should affect findutils and coreutils are minor performance p

Re: findutils 4.6.0 v. Tru64 (strftime() v. "%F"?)

On 05/25/2017 07:54 AM, Eric Blake wrote: So yes, either findutils should be using nstrftime() and not strftime() (which will guarantee that these sequences work), or it is indeed time to patch gnulib to provide a replacement strftime() on platforms that are not POSIX-compliant (and then still pa

Re: [bug #48055] Regex ranges and locales in gnu-awk regextype

James Youngman wrote: Findutils uses the regular expression implementation from gnulib. So this problem likely also exists there, or perhaps has already been fixed there. I can't seem to reproduce the problem on Fedora 24, so perhaps it's been fixed already. $ ls a.lower b.UPPER $ LC_COLLA

Re: __attribute__ and timespec_t problems building findutils on IRIX

This looks like a case that's similar to what's handled by the following code in gnulib/lib/sys_select.in.h: /* On IRIX 6.5, includes , which includes , which includes . At this point we cannot include , because that includes , which gives a syntax error because has not been comp

Re: __attribute__ and timeval problems building findutils on IRIX

Eric Blake wrote: Rather, we should be fixing gnulib's replacement header to be self-contained. How is HAVE_STRUCT_TIMEVAL defined in that build? If it's defined, why did the configure-time test for 'struct timeval' work even though test-gettimeofday.c does not work? If it's not defined, w

Re: a minor bug

James Youngman wrote: +static FILE* fopen_cloexec_for_read_only (const char *file_name) { + int fd = open_cloexec (file_name, O_RDONLY); + return (fd < 0) ? NULL : fdopen (fd, "r"); +} This should close fd if fdopen fails, no? Also, the indentation should be fixed to be GNU-like.

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

Follow-up Comment #12, bug #38474 (project findutils): > In the case of -perm, there is no existing file mode. Sure, but POSIX says that find should treat the existing file mode as 0 here. For example, POSIX says that "find /tmp -perm +rw" finds all files under /tmp that are read-write to everyo

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

Follow-up Comment #10, bug #38474 (project findutils): Thanks for catching that problem with 'havekind'. A patch is attached. I don't think the code should reject -perm /+0111, or -+0111 for that matter. 'chmod +0111 foo' has a well-defined meaning with GNU chmod, and it's nicer if 'find' is c

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

Follow-up Comment #7, bug #38474 (project findutils): Let's follow Eric's mild preference and make it an error. I'm attaching a proposed patch. (file #27916) ___ Additional Item Attachment: File name: patch.txt Size:7

[bug #38791] doc: fix typos uncovered by texinfo 5.0

ity: 3 - Normal Item Group: Compilation Failure Status: None Privacy: Public Assigned to: None Originator Name: Paul Eggert Originator Email: Open/Closed: Open Discussion Lock: Any R

Re: [PATCH] fts: reduce two or more trailing spaces to just one, usually

On 11/16/12 14:10, Dmitry V. Levin wrote: > As I said, my proposal is to introduce a new FTS_ flag that would make > fts_open behave as before that change, and use this flag in findutils. > I haven't heard yet neither from Jim nor from other gnulib people whether > it is acceptable or there is a be

Re: [PATCH] fts: introduce FTS_NOATIME

On 07/07/11 10:41, Eric Blake wrote: > This gives clients the option to try a non-invasive traversal, Thanks for doing that; a couple of minor comments: > -int fd = open (".", O_SEARCH); > +int fd = open (".", > + O_SEARCH | (ISSET (FTS_NOATIME) ?

Re: human interface change?!? [Re: xstrtol.h

Jim Meyering <[EMAIL PROTECTED]> writes: > All of your changes look fine, modulo Eric's test catch. > You're welcome to check in the gnulib part. > Then I'll do the coreutils bits. OK, thanks, I checked in the gnulib part (with Eric's test catch). ___

Re: human interface change?!? [Re: xstrtol.h

tion of the 'for' loop after the patch. 2007-08-10 Paul Eggert <[EMAIL PROTECTED]> * locate/locate.c (dolocate): Adjust to API change of xstrtol gnulib module. * po/POTFILES.in: Likewise. Index: locate/locate.c ==

Re: human interface change?!? [Re: xstrtol.h

Jim Meyering <[EMAIL PROTECTED]> writes: > find's locate.c uses it, too. Thanks for mentioning that. Here's a patch for that, which I've verified with 'make check' in findutils. It can be installed if the proposed gnulib change is OK. 2007-08-

Re: re_compile_pattern change

"James Youngman" <[EMAIL PROTECTED]> writes: > I'll consider myself notified.Apart from that bugfix are there any > other essential changes I should import, or are you suggesting I > update the whole of gnulib to current CVS? Generally speaking, I find it easiest just to sync all of gnulib. T

Re: re_compile_pattern change

[EMAIL PROTECTED] writes: > One difference I noted in the test code used between tar-1.16.1 and > findutils-4.2.29 (2.60 vs 2.60a) was: > > tar: s = re_compile_pattern ("a[[:]:]]b\n", 11, ®ex); > findutils: s = re_compile_pattern ("a[:]:]b\n", 9, ®ex); > > A printf in both shows that tar say

Re: Incompatibility between current gnulib and gettext-0.14.6?

On 11/25/06, James Youngman <[EMAIL PROTECTED]> wrote: > I am using gettext version 0.14.6. Its version of po/Makefile.in.in > uses @MKINSTALLDIRS@, mkinstalldirs is obsolete and is not maintained any more, and new distributions shouldn't distribute it. install-sh now does the work that mkinsta

Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

"James Youngman" <[EMAIL PROTECTED]> writes: > I'm very reluctant to try opening every file in the > filesystem just in case it turns out to be a directory we need to > descend into. Your reluctance is understandable, since it is incorrect to always open every directory entry. The corresponding

Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

Miklos Szeredi <[EMAIL PROTECTED]> writes: > From what I understand, the solution for the find > problem will actually make fts more optimal in some cases even for > POSIX filesystems, and will cause no regressions whatsoever. If so, then that's good for fts. The problem will continue to remain

Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

Miklos Szeredi <[EMAIL PROTECTED]> writes: > If you were thinking of a soltuion, where the filesystem itself > supplies two different inode numbers based on the variant of the > userspace interface, then I'm sorry to inform you, that this sort of > interface is not likely to happen in the Linux ke

Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

Miklos Szeredi <[EMAIL PROTECTED]> writes: > The legacy app will break regardless of how many files there are on > the filesystem, or even wheter it needs to use the inode number or > not. It will break because the stat() family of syscalls will return > with an error. I don't see why. The kern

Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

Miklos Szeredi <[EMAIL PROTECTED]> writes: >> If it's for legacy apps, tell people to recompile with largefile >> support. > > Paul, please! It is ridiculous to require end users to recompile > their applications or kernels or anything. A small-file legacy app, one that cannot handle files large

Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

Miklos Szeredi <[EMAIL PROTECTED]> writes: >> If files are identified by the path, then you can hash the >> path. If you use a good 64-bit hash the chance of collision >> is practically zero. That's good enough. > > Yes. And this solution is actually practical on pure 64bit > archs only. On 32bi

[bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

Follow-up Comment #11, bug #17877 (project findutils): >> if some Linux-based file systems can't provide stable >> inode numbers, they should be fixed so that they do. It >> shouldn't be that hard. > > It's not hard, it's impossible. Take for example path > based network filesystems (smbfs, sshf

[bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

Follow-up Comment #9, bug #17877 (project findutils): Miklos Szeredi <[EMAIL PROTECTED]> writes: > What the patch does is to release the inode as > soon as there are no more references to it. Sorry, but that's going to break lots of code. It's not just gnulib; it's lots of other uses as well.

Re: filutils 4.1

Jim Meyering <[EMAIL PROTECTED]> writes: > I think it would be worth maintaining. Me too. The gnulib stat-time should make it pretty easy. I can write up a patch if you like. ___ Bug-findutils mailing list Bug-findutils@gnu.org http://lists.gnu.org/

[bug #17438] find doesn't bootstrap from CVS

Follow-up Comment #2, bug #17438 (project findutils): Sorry, that was due to a gnulib bug introduced on Thursday. I've fixed the gnulib bug, so if you refetch gnulib you should be OK. ___ Reply to this item at:

[bug #17437] find mishandles symbolic permissions that have "X"

Follow-up Comment #2, bug #17437 (project findutils): Yes, perm.texi came from coreutils. ___ Reply to this item at: ___ Message sent via/by Savannah

[bug #17438] find doesn't bootstrap from CVS

URL: Summary: find doesn't bootstrap from CVS Project: findutils Submitted by: eggert Submitted on: Tuesday 08/15/2006 at 14:30 Category: find Severity: 3 - Normal

[bug #17437] find mishandles symbolic permissions that have "X"

URL: Summary: find mishandles symbolic permissions that have "X" Project: findutils Submitted by: eggert Submitted on: Tuesday 08/15/2006 at 14:20 Category: find Sever

Re: findutils 4.2.27 on IRIX 5.3

Georg Schwarz <[EMAIL PROTECTED]> writes: > I can build the latest coreutils (5.93) > So gnulib should compile, shouldn't it? gnulib should compile on a C89-or-better host, yes. In theory findutils could be using part of gnulib that coreutils is not, which would mean that building coreutils isn'

Re: findutils 4.2.27 on IRIX 5.3

[EMAIL PROTECTED] (James Youngman) writes: > Later versions (1995, I think) of the ANSI C standard require it. The > file which you can't compile is part of gnulib, but gnulib only builds > on ANSI-standard-compliant systems. As a rule gnulib assumes only C89; it does not assume the later exte

Re: findutils-4.2.26 build error on HP-UX 10.20

James Youngman <[EMAIL PROTECTED]> writes: > I'm copying this email to the gnulib project, in case they want to > apply the patch anyway (the gnulib subdirectory of the findutils > source code is just imported from the gnulib project). That patch doesn't look right to me. gnulib/modules/mbchar s

Re: stat and lstat should define their replacements

Derek Price <[EMAIL PROTECTED]> writes: > I can install it if no one has any further objections. Please install it in gnulib; it looks good to me. Thanks for following up on it. ___ Bug-findutils mailing list Bug-findutils@gnu.org http://lists.gnu.or

Re: flag for one second timestamp comparison granularity

James Youngman <[EMAIL PROTECTED]> writes: > If the timestamps are different, they're different. After all, why > stop at one second? The MS-DOS FAT filesystem has a two-second > granularity and I don't hear people clamouring to have a feature where > the time values for tools are computed &(~1)

Re: stat and lstat should define their replacements

Derek Price <[EMAIL PROTECTED]> writes: > What does this mean for Bruno's recent patch for stat & lstat which > removed the SunOS 4.1.4 support in addition to some other fixes? His patch made sense to me, but as far as I know nobody has taken the time to integrate the comments on it and try it ou

Re: [bug-gnulib] Re: findutils doesn't compile on sunos 4.1.4

James Youngman <[EMAIL PROTECTED]> writes: > Findutils uses a substantial amount of gnulib code; I would not want > the gnulib maintainers to think that I thought they should put in > extra effort to maintain support for SunOS 4.1.4. I wouldn't object to minor and obvious tweaks that are checked

Re: findutils POSIX incompatiblity with "find . -perm ++w -print"

I did notice one minor inefficiency in the patch . that I submitted yesterday. This code: if (argv[*arg_ptr][0] == '+' && (change = mode_compile (argv[*arg_ptr]))) ... can be replaced by: change = mode_compile (ar

findutils POSIX incompatiblity with "find . -perm ++w -print"

ter and it looks a bit like the "or" symbol. Here is a patch. 2005-05-23 Paul Eggert <[EMAIL PROTECTED]> * NEWS: Mention the new "find ... -perm /MODE" syntax, which replaces the "find ... -perm +MODE" syntax (which was incompatible with POSIX

Re: [Patch] mode_* when compiling findutils with fresh gnulib

ct that config.rpath now lives in gnulib/build-aux. So I propose this patch to findutils. 2005-05-23 Paul Eggert <[EMAIL PROTECTED]> Adjust to recent gnulib changes. * import-gnulib.sh: Get config.rpath from gnulib/build-aux, not gnulib/config. * find/parse

Re: [bug-gnulib] Re: [patch #3741] Added support for Interix within mountlist.c

Jim Meyering <[EMAIL PROTECTED]> writes: > + /* In the unlikely event that opendir and each readdir > +succeed, but all statvfs calls fail, ensure that we > +fail with a valid errno value. */ If I'm understanding the code correctly, the comment should read "a statvfs call fai