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

From: Philipp <[email-masked]>
Date: Mon, 17 May 2021 21:37:42 +0200

> Am 17.05.2021 um 02:23 schrieb Dmitry Gutov <[email-masked]>:
> 
> 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.