bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Philipp]

The following happens at least on macOS with its BSD find.  It does
*not* happen with GNU find.

Create an empty directory /tmp/foo and files bar and baz in that
directory.  Then, define a trivial project:

(cl-defmethod project-roots ((_ (eql foo))) '("/tmp/foo/"))
(cl-defmethod project-ignores ((_ (eql foo)) _) '("./bar"))

The important point here is that the project root is a directory name,
not a directory file name.

Now, with macOS find:

(project-files 'foo)
=> ("/tmp/foo//bar" "/tmp/foo//baz")

Note how the `project-ignores' result has been ignored.  The problem is
that macOS find doesn't normalize the directory name in any way:

/tmp/foo$ find /tmp/foo/
/tmp/foo/
/tmp/foo//baz
/tmp/foo//bar

/tmp/foo$ find /tmp/foo/ '(' -path /tmp/foo/bar -prune ')' -o -print
/tmp/foo/
/tmp/foo//baz
/tmp/foo//bar

/tmp/foo$ find /tmp/foo/ '(' -path /tmp/foo//bar -prune ')' -o -print
/tmp/foo/
/tmp/foo//baz

XRef will generate a prune pattern like /tmp/foo/bar, and find will
ignore it because it doesn't exactly match the filenames.

To work around this, XRef should probably only pass directory file names
to find, not directory names, at least on macOS.


In GNU Emacs 28.0.50 (build 119, aarch64-apple-darwin20.4.0, NS appkit-2022.44 Version 11.3.1 (Build 20E241))
 of 2021-05-16
Repository revision: 0212fb180a118795b4de383cc712e7079c998cef
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.3.1

Configured using:
 'configure --with-modules --without-xml2 --without-pop --with-mailutils
 --enable-gcc-warnings=warn-only --enable-checking=all
 --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0''

Configured features:
ACL GNUTLS JSON LCMS2 MODULES NOTIFY KQUEUE NS PDUMPER PNG THREADS
TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822
mml mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs time-date
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils phst skeleton derived edmacro kmacro pcase ffap thingatpt url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json map url-vars mailcap rx
gnutls puny dbus xml subr-x seq byte-opt gv bytecomp byte-compile cconv
compile text-property-search comint ansi-color ring cl-loaddefs cl-lib
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 70856 6582)
 (symbols 48 8362 1)
 (strings 32 24246 2104)
 (string-bytes 1 792999)
 (vectors 16 16049)
 (vector-slots 8 212521 6692)
 (floats 8 26 28)
 (intervals 56 220 0)
 (buffers 992 10))

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Dmitry Gutov]

Hi!

On 16.05.2021 23:05, Philipp wrote:
> To work around this, XRef should probably only pass directory file names
> to find, not directory names, at least on macOS.

Could you track down the piece of code that's misbehaving? Maybe with a 
little edebug-ing.

I don't have any BSD find at hand, but

   (xref--find-ignores-arguments '("./bar") "/tmp/foo/")

returns

   "\\( -path /tmp/foo/bar \\) -prune -o "

here.

Also, your return value of (project-files 'foo) seems to indicate that 
you're using the version of project.el that doesn't include the commit 
665b4e7c4e093391a353506e7b2385f0902db70b. Please see if it fixed this 
problem as well.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Philipp]

> Am 17.05.2021 um 02:23 schrieb Dmitry Gutov <dgutov@yandex.ru>:
> 
> Hi!
> 
> On 16.05.2021 23:05, Philipp wrote:
>> To work around this, XRef should probably only pass directory file names
>> to find, not directory names, at least on macOS.
> 
> Could you track down the piece of code that's misbehaving? Maybe with a little edebug-ing.
> 
> I don't have any BSD find at hand, but
> 
>  (xref--find-ignores-arguments '("./bar") "/tmp/foo/")
> 
> returns
> 
>  "\\( -path /tmp/foo/bar \\) -prune -o "
> 
> here.

Yes, and that's the problem.  macOS find compares the "-path" value against /tmp/foo//bar (note the double slash), and that doesn't match.  The exact shell command generated by project--files-in-directory is:

  find /tmp/foo/ \( -path /tmp/foo/bar \) -prune -o  -type f  -print0

And that doesn't work on macOS:

$ find /tmp/foo/ \( -path /tmp/foo/bar \) -prune -o  -type f  -print
/tmp/foo//baz
/tmp/foo//bar

This needs to be either "find /tmp/foo ..." (no trailing slash) or "-path /tmp/foo//bar" (double slash).  However, the latter than fails with GNU find:

$ gfind /tmp/foo/ \( -path /tmp/foo//bar \) -prune -o  -type f  -print
/tmp/foo/baz
/tmp/foo/bar

So probably it's better to use the former option.  That works with both both macOS find and GNU find:

$ find /tmp/foo \( -path /tmp/foo/bar \) -prune -o  -type f  -print
/tmp/foo/baz
$ gfind /tmp/foo \( -path /tmp/foo/bar \) -prune -o  -type f  -print
/tmp/foo/baz

There's a comment in project--files-in-directory ";; In case DIR is a symlink."  Probably the command should use the -H option instead.

> 
> Also, your return value of (project-files 'foo) seems to indicate that you're using the version of project.el that doesn't include the commit 665b4e7c4e093391a353506e7b2385f0902db70b. Please see if it fixed this problem as well.

This was a build from yesterday, it should definitely include that commit.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Philipp]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]



> Am 17.05.2021 um 21:37 schrieb Philipp <p.stephani2@gmail.com>:
> 
> 
> 
>> Am 17.05.2021 um 02:23 schrieb Dmitry Gutov <dgutov@yandex.ru>:
>> 
>> Hi!
>> 
>> On 16.05.2021 23:05, Philipp wrote:
>>> To work around this, XRef should probably only pass directory file names
>>> to find, not directory names, at least on macOS.
>> 
>> Could you track down the piece of code that's misbehaving? Maybe with a little edebug-ing.
>> 
>> I don't have any BSD find at hand, but
>> 
>> (xref--find-ignores-arguments '("./bar") "/tmp/foo/")
>> 
>> returns
>> 
>> "\\( -path /tmp/foo/bar \\) -prune -o "
>> 
>> here.
> 
> Yes, and that's the problem.  macOS find compares the "-path" value against /tmp/foo//bar (note the double slash), and that doesn't match.  The exact shell command generated by project--files-in-directory is:
> 
>  find /tmp/foo/ \( -path /tmp/foo/bar \) -prune -o  -type f  -print0
> 
> And that doesn't work on macOS:
> 
> $ find /tmp/foo/ \( -path /tmp/foo/bar \) -prune -o  -type f  -print
> /tmp/foo//baz
> /tmp/foo//bar
> 
> This needs to be either "find /tmp/foo ..." (no trailing slash) or "-path /tmp/foo//bar" (double slash).  However, the latter than fails with GNU find:
> 
> $ gfind /tmp/foo/ \( -path /tmp/foo//bar \) -prune -o  -type f  -print
> /tmp/foo/baz
> /tmp/foo/bar
> 
> So probably it's better to use the former option.  That works with both both macOS find and GNU find:
> 
> $ find /tmp/foo \( -path /tmp/foo/bar \) -prune -o  -type f  -print
> /tmp/foo/baz
> $ gfind /tmp/foo \( -path /tmp/foo/bar \) -prune -o  -type f  -print
> /tmp/foo/baz
> 
> There's a comment in project--files-in-directory ";; In case DIR is a symlink."  Probably the command should use the -H option instead.

The attached patch fixes both unit tests for project.el on my macOS system.

[-- Attachment #2: 0001-Fix-find-invocation-for-macOS-Bug-48471.patch --]
[-- Type: application/octet-stream, Size: 1496 bytes --]

From 08e862623eb696a7c3df0404784abf34ed0d1ab6 Mon Sep 17 00:00:00 2001
From: Philipp Stephani <phst@google.com>
Date: Mon, 17 May 2021 21:59:57 +0200
Subject: [PATCH] Fix find invocation for macOS (Bug#48471).

* lisp/progmodes/project.el (project--files-in-directory): Instead of
appending a slash (which doesn't work well with macOS find), remove
trailing slash and pass -H instead.
---
 lisp/progmodes/project.el | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 047f55ed1a..eab60756c8 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -297,11 +297,10 @@ project--files-in-directory
          ;; expanded and not left for the shell command
          ;; to interpret.
          (localdir (file-name-unquote (file-local-name (expand-file-name dir))))
-         (command (format "%s %s %s -type f %s -print0"
+         (command (format "%s -H %s %s -type f %s -print0"
                           find-program
                           (shell-quote-argument
-                           ;; In case DIR is a symlink.
-                           (file-name-as-directory localdir))
+                           (directory-file-name localdir)) ; Bug#48471
                           (xref--find-ignores-arguments ignores localdir)
                           (if files
                               (concat (shell-quote-argument "(")
-- 
2.30.1 (Apple Git-130)

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Dmitry Gutov]

On 17.05.2021 23:02, Philipp wrote:
> The attached patch fixes both unit tests for project.el on my macOS system.

Thanks, now I think I understand the problem. And you're suggesting the 
alternative solution also proposed previously in the 
https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00156.html 
discussion.

Please go ahead with the patch, though it would be better to use a 
version of it which fixes the same behavior in two other related 
functions as well. The previous patch for that approach is here: 
https://lists.gnu.org/archive/html/emacs-devel/2021-01/txtDduOxGoiGz.txt

(From the message 
https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00345.html).

Also, since it will fix the double-slash problem, we can undo the change 
from 331e40a8fd491ceb35c08a3345785dab61bc60d9, the one that made our 
comparisons lax (to match both single and double slashes).

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Philipp]

> Am 18.05.2021 um 01:06 schrieb Dmitry Gutov <dgutov@yandex.ru>:
> 
> On 17.05.2021 23:02, Philipp wrote:
>> The attached patch fixes both unit tests for project.el on my macOS system.
> 
> Thanks, now I think I understand the problem. And you're suggesting the alternative solution also proposed previously in the https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00156.html discussion.
> 
> Please go ahead with the patch,

Thanks, I've installed the patch as commit 2e55201b8085d64c76d9a35bffff90a02133647e.

> though it would be better to use a version of it which fixes the same behavior in two other related functions as well. The previous patch for that approach is here: https://lists.gnu.org/archive/html/emacs-devel/2021-01/txtDduOxGoiGz.txt
> 
> (From the message https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00345.html).
> 
> Also, since it will fix the double-slash problem, we can undo the change from 331e40a8fd491ceb35c08a3345785dab61bc60d9, the one that made our comparisons lax (to match both single and double slashes).

I'm also fine with either of those, but we should first make sure that the code in question is well-covered by unit tests to avoid regressions.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Dmitry Gutov]

On 23.05.2021 14:08, Philipp wrote:
>> though it would be better to use a version of it which fixes the same behavior in two other related functions as well. The previous patch for that approach is here:https://lists.gnu.org/archive/html/emacs-devel/2021-01/txtDduOxGoiGz.txt
>>
>> (From the messagehttps://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00345.html).
>>
>> Also, since it will fix the double-slash problem, we can undo the change from 331e40a8fd491ceb35c08a3345785dab61bc60d9, the one that made our comparisons lax (to match both single and double slashes).
> I'm also fine with either of those, but we should first make sure that the code in question is well-covered by unit tests to avoid regressions.

Tests are good to have, yes.

Speaking of the implementation, any chance we would want to have "-H" 
inside grep-find-template by default?

Has that been considered in the past perhaps? Eli, Lars, Stefan?

The simplest change to that effect should look like this:

diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el
index e9fbcbbfcd..9956ba79d0 100644
--- a/lisp/progmodes/grep.el
+++ b/lisp/progmodes/grep.el
@@ -777,19 +777,19 @@ grep-compute-defaults
  				(format "%s " (null-device))
  			      "")))
  		  (cond ((eq grep-find-use-xargs 'gnu)
-			 (format "%s <D> <X> -type f <F> -print0 | \"%s\" -0 %s"
+			 (format "%s -H <D> <X> -type f <F> -print0 | \"%s\" -0 %s"
  				 find-program xargs-program gcmd))
  			((eq grep-find-use-xargs 'gnu-sort)
-			 (format "%s <D> <X> -type f <F> -print0 | sort -z | \"%s\" -0 %s"
+			 (format "%s -H <D> <X> -type f <F> -print0 | sort -z | \"%s\" -0 %s"
  				 find-program xargs-program gcmd))
  			((eq grep-find-use-xargs 'exec)
-			 (format "%s <D> <X> -type f <F> -exec %s %s %s%s"
+			 (format "%s -H <D> <X> -type f <F> -exec %s %s %s%s"
  				 find-program gcmd quot-braces null quot-scolon))
  			((eq grep-find-use-xargs 'exec-plus)
-			 (format "%s <D> <X> -type f <F> -exec %s %s%s +"
+			 (format "%s -H <D> <X> -type f <F> -exec %s %s%s +"
  				 find-program gcmd null quot-braces))
  			(t
-			 (format "%s <D> <X> -type f <F> -print | \"%s\" %s"
+			 (format "%s -H <D> <X> -type f <F> -print | \"%s\" %s"
  				 find-program xargs-program gcmd))))))))

      ;; Save defaults for this host.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Speaking of the implementation, any chance we would want to have "-H"
> inside grep-find-template by default?
>
> Has that been considered in the past perhaps? Eli, Lars, Stefan?

I'm surprised that it isn't already in there, so unless there's some
compatibility problem (with some grep versions not having -H), I think
your patch looks good.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Dmitry Gutov]

On 30.05.2021 07:29, Lars Ingebrigtsen wrote:
> (with some grep versions not having -H)

Versions of 'find', you mean.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 30.05.2021 07:29, Lars Ingebrigtsen wrote:
>> (with some grep versions not having -H)
>
> Versions of 'find', you mean.

Ah, yes indeed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 30 May 2021 00:44:40 +0300
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>, 48471@debbugs.gnu.org,
>  Stefan Monnier <monnier@IRO.UMontreal.CA>
> 
> Speaking of the implementation, any chance we would want to have "-H" 
> inside grep-find-template by default?

It's in Posix, but I'm not sure how portable it is in practice.  Paul,
Andreas, do you happen to know?

Perhaps for 100% portability we should probe for its support?

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Dmitry Gutov]

On 30.05.2021 09:31, Eli Zaretskii wrote:
> It's in Posix, but I'm not sure how portable it is in practice.  Paul,
> Andreas, do you happen to know?
> 
> Perhaps for 100% portability we should probe for its support?

Since even the ancient BSD find on Macs supports it, I figured it's 
widespread enough. But if people say otherwise, I suppose we could add a 
probe.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Paul Eggert]

On 5/29/21 11:31 PM, Eli Zaretskii wrote:
> It's in Posix, but I'm not sure how portable it is in practice.  Paul,
> Andreas, do you happen to know?

Although 'find -H' was not in 7th edition Unix, it was added reasonably 
soon after that and it should be in all currently-supported POSIXish 
platforms.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Eli Zaretskii]

> Cc: p.stephani2@gmail.com, larsi@gnus.org, 48471@debbugs.gnu.org,
>  monnier@IRO.UMontreal.CA
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 30 May 2021 09:27:34 -0700
> 
> On 5/29/21 11:31 PM, Eli Zaretskii wrote:
> > It's in Posix, but I'm not sure how portable it is in practice.  Paul,
> > Andreas, do you happen to know?
> 
> Although 'find -H' was not in 7th edition Unix, it was added reasonably 
> soon after that and it should be in all currently-supported POSIXish 
> platforms.

Thanks, I guess it's safe to use it then.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Dmitry Gutov]

Version: 28.1

On 30.05.2021 19:36, Eli Zaretskii wrote:
>> Cc: p.stephani2@gmail.com, larsi@gnus.org, 48471@debbugs.gnu.org,
>>   monnier@IRO.UMontreal.CA
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Sun, 30 May 2021 09:27:34 -0700
>>
>> On 5/29/21 11:31 PM, Eli Zaretskii wrote:
>>> It's in Posix, but I'm not sure how portable it is in practice.  Paul,
>>> Andreas, do you happen to know?
>>
>> Although 'find -H' was not in 7th edition Unix, it was added reasonably
>> soon after that and it should be in all currently-supported POSIXish
>> platforms.
> 
> Thanks, I guess it's safe to use it then.

Thanks, pushed as commit 45bdc37c81.

Philipp, Daniel, if you could verify that the code still works fine, and 
the updated (mostly reverted) tests still pass on your systems, that 
would be great.

In the meantime, closing.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dgutov@yandex.ru> writes:

>
> Philipp, Daniel, if you could verify that the code still works fine,
> and the updated (mostly reverted) tests still pass on your systems,
> that would be great.
>
> In the meantime, closing.

I confirm that the tests pass fine on macOS 11.4.  Thanks.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Philipp]

> Am 07.06.2021 um 03:58 schrieb Dmitry Gutov <dgutov@yandex.ru>:
> 
> Version: 28.1
> 
> On 30.05.2021 19:36, Eli Zaretskii wrote:
>>> Cc: p.stephani2@gmail.com, larsi@gnus.org, 48471@debbugs.gnu.org,
>>>  monnier@IRO.UMontreal.CA
>>> From: Paul Eggert <eggert@cs.ucla.edu>
>>> Date: Sun, 30 May 2021 09:27:34 -0700
>>> 
>>> On 5/29/21 11:31 PM, Eli Zaretskii wrote:
>>>> It's in Posix, but I'm not sure how portable it is in practice.  Paul,
>>>> Andreas, do you happen to know?
>>> 
>>> Although 'find -H' was not in 7th edition Unix, it was added reasonably
>>> soon after that and it should be in all currently-supported POSIXish
>>> platforms.
>> Thanks, I guess it's safe to use it then.
> 
> Thanks, pushed as commit 45bdc37c81.
> 
> Philipp, Daniel, if you could verify that the code still works fine, and the updated (mostly reverted) tests still pass on your systems, that would be great.

All XRef and project tests still pass on my machine, thanks.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Paul Eggert]

On 10/9/21 2:53 PM, Dmitry Gutov wrote:
> Hi Paul,
> 
> Hi Philipp,
> 
> On 30.05.2021 19:27, Paul Eggert wrote:
>> On 5/29/21 11:31 PM, Eli Zaretskii wrote:
>>> It's in Posix, but I'm not sure how portable it is in practice.  Paul,
>>> Andreas, do you happen to know?
>>
>> Although 'find -H' was not in 7th edition Unix, it was added 
>> reasonably soon after that and it should be in all currently-supported 
>> POSIXish platforms.
> 
> Any chance we could say the same about '-printf'?
> 
> It would help speed up our default 'project-files' implementation by 
> about 10%.


Unfortunately not. find -printf is not standardized by POSIX and is 
missing on (for example) Solaris 10.

Perhaps you could do a quick test of whether 'find -printf' works, and 
use -printf only if it works.

bug#48471: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD find?) if project root is a directory name

[Dmitry Gutov]

On 10.10.2021 01:07, Paul Eggert wrote:
> On 10/9/21 2:53 PM, Dmitry Gutov wrote:
>> Any chance we could say the same about '-printf'?
> 
> Unfortunately not. find -printf is not standardized by POSIX and is 
> missing on (for example) Solaris 10.

I see, thank you.

> Perhaps you could do a quick test of whether 'find -printf' works, and 
> use -printf only if it works.

Yeah, that's an option.

But a meaningful test whether 'find' works seems a bit less obvious to 
design than the existing tests in grep.el I could otherwise adapt.

Something to consider for future developments in Emacs 29 anyway.