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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48471 in the body.
You can then email your comments to 48471 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Incorrect handling of `project-ignores' on macOS (BSD
 find?) if project root is a directory name
Date: Sun, 16 May 2021 22:05:21 +0200

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

Message #8 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Philipp <p.stephani2 <at> gmail.com>, 48471 <at> debbugs.gnu.org
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Mon, 17 May 2021 03:23:43 +0300

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.

Message #11 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 48471 <at> debbugs.gnu.org
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Mon, 17 May 2021 21:37:42 +0200

> Am 17.05.2021 um 02:23 schrieb Dmitry Gutov <dgutov <at> 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.

Message #14 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 48471 <at> debbugs.gnu.org
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Mon, 17 May 2021 22:02:42 +0200

[Message part 1 (text/plain, inline)]

> Am 17.05.2021 um 21:37 schrieb Philipp <p.stephani2 <at> gmail.com>:
> 
> 
> 
>> Am 17.05.2021 um 02:23 schrieb Dmitry Gutov <dgutov <at> 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.

[0001-Fix-find-invocation-for-macOS-Bug-48471.patch (application/octet-stream, attachment)]

Message #17 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: 48471 <at> debbugs.gnu.org
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Tue, 18 May 2021 02:06:51 +0300

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

Message #20 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 48471 <at> debbugs.gnu.org
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Sun, 23 May 2021 13:08:14 +0200

> Am 18.05.2021 um 01:06 schrieb Dmitry Gutov <dgutov <at> 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.

Message #23 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Philipp <p.stephani2 <at> gmail.com>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 48471 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Sun, 30 May 2021 00:44:40 +0300

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.

Message #26 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Philipp <p.stephani2 <at> gmail.com>, 48471 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Sun, 30 May 2021 06:29:03 +0200

Dmitry Gutov <dgutov <at> 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

Message #29 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Andreas Schwab <schwab <at> linux-m68k.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: p.stephani2 <at> gmail.com, 48471 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> IRO.UMontreal.CA
Subject: Re: bug#48471: 28.0.50;
 Incorrect handling of `project-ignores' on macOS (BSD find?) if
 project root is a directory name
Date: Sun, 30 May 2021 09:31:56 +0300

> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sun, 30 May 2021 00:44:40 +0300
> Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 48471 <at> debbugs.gnu.org,
>  Stefan Monnier <monnier <at> 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?

Message #32 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Philipp <p.stephani2 <at> gmail.com>, 48471 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Sun, 30 May 2021 14:13:21 +0300

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

Versions of 'find', you mean.

Message #35 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Andreas Schwab <schwab <at> linux-m68k.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: p.stephani2 <at> gmail.com, 48471 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> IRO.UMontreal.CA
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Sun, 30 May 2021 14:14:45 +0300

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.

Message #38 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Cc: p.stephani2 <at> gmail.com, 48471 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> IRO.UMontreal.CA
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
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.

Message #41 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: p.stephani2 <at> gmail.com, 48471 <at> debbugs.gnu.org, schwab <at> linux-m68k.org,
 monnier <at> IRO.UMontreal.CA, dgutov <at> yandex.ru, larsi <at> gnus.org
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Sun, 30 May 2021 19:36:59 +0300

> Cc: p.stephani2 <at> gmail.com, larsi <at> gnus.org, 48471 <at> debbugs.gnu.org,
>  monnier <at> IRO.UMontreal.CA
> From: Paul Eggert <eggert <at> 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.

Message #44 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Philipp <p.stephani2 <at> gmail.com>, 48471 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Mon, 31 May 2021 07:33:13 +0200

Dmitry Gutov <dgutov <at> 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

Message #49 received at 48471-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, 48471-done <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Mon, 7 Jun 2021 04:58:21 +0300

Version: 28.1

On 30.05.2021 19:36, Eli Zaretskii wrote:
>> Cc: p.stephani2 <at> gmail.com, larsi <at> gnus.org, 48471 <at> debbugs.gnu.org,
>>   monnier <at> IRO.UMontreal.CA
>> From: Paul Eggert <eggert <at> 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.

Message #52 received at 48471-done <at> debbugs.gnu.org (full text, mbox):

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, p.stephani2 <at> gmail.com,
 48471-done <at> debbugs.gnu.org
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Mon, 07 Jun 2021 10:51:56 +0200

Dmitry Gutov <dgutov <at> 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.

Message #55 received at 48471-done <at> debbugs.gnu.org (full text, mbox):

From: Philipp <p.stephani2 <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 48471-done <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Mon, 7 Jun 2021 20:48:30 +0200

> Am 07.06.2021 um 03:58 schrieb Dmitry Gutov <dgutov <at> yandex.ru>:
> 
> Version: 28.1
> 
> On 30.05.2021 19:36, Eli Zaretskii wrote:
>>> Cc: p.stephani2 <at> gmail.com, larsi <at> gnus.org, 48471 <at> debbugs.gnu.org,
>>>  monnier <at> IRO.UMontreal.CA
>>> From: Paul Eggert <eggert <at> 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.

Message #62 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 48471 <at> debbugs.gnu.org
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Sat, 9 Oct 2021 15:14:54 -0700

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.

Message #65 received at 48471 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <at> gnu.org>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Cc: p.stephani2 <at> gmail.com, 48471 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> IRO.UMontreal.CA
Subject: Re: bug#48471: 28.0.50; Incorrect handling of `project-ignores' on
 macOS (BSD find?) if project root is a directory name
Date: Sun, 10 Oct 2021 01:29:37 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.