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

0001-Fix-find-invocation-for-macOS-Bug-48471.patch
Description: Binary data