[BUG] `--exclude` quirk, only seems to affect first `--search-path` in some cases (without glob)

[luckman212]

Checks

• I have read the troubleshooting section and still think this is a bug.

Bug

I believe this is a bug. It's probably at least tangentially related to #851, #374, and #1577.

When multiple --search-path arguments are supplied, fd appears to ignore (not respect) the --exclude directive when processing dirs after the first search path.

Repro

I wrote a very simple bash script to repro this:

#!/usr/bin/env bash

fd --version

echo "only 'myfile1.txt' should be found"
echo

# dir1
mkdir -p ~/test/abc/def
mkdir -p ~/test/ghi/def
touch ~/test/abc/def/myfile1.txt
touch ~/test/ghi/def/myfile2.txt

# dir2
mkdir -p ~/test2/abc/def
mkdir -p ~/test2/ghi/def
touch ~/test2/abc/def/myfile1.txt
touch ~/test2/ghi/def/myfile2.txt

echo "this works: --exclude 'ghi'"
fd --type file --search-path ~/test --search-path ~/test2 --exclude 'ghi'
echo

echo "this also works: --exclude '**/ghi/def'"
fd --type file --search-path ~/test --search-path ~/test2 --exclude '**/ghi/def'
echo

echo "this seems to NOT work as expected: --exclude 'ghi/def'"
echo "(~/test2/ghi/def/myfile2.txt will be shown)"
fd --type file --search-path ~/test --search-path ~/test2 --exclude 'ghi/def'

Output

$ ./fd_repro.sh
fd 10.4.2
only 'myfile1.txt' should be found

this works: --exclude 'ghi'
/Users/luke/test/abc/def/myfile1.txt
/Users/luke/test2/abc/def/myfile1.txt

this also works: --exclude '**/ghi/def'
/Users/luke/test/abc/def/myfile1.txt
/Users/luke/test2/abc/def/myfile1.txt

this seems to NOT work as expected: --exclude 'ghi/def'
(~/test2/ghi/def/myfile2.txt will be shown)
/Users/luke/test/abc/def/myfile1.txt
/Users/luke/test2/abc/def/myfile1.txt
/Users/luke/test2/ghi/def/myfile2.txt

Describe what you expected to happen:

Did not expect any of the commands to surface /Users/luke/test2/ghi/def/myfile2.txt

What version of fd are you using?

fd 10.4.2

Which operating system / distribution are you on?

macOS 26.3.2 (25D2140)

[tmccombs]

The issue here is that we currently use the first search path as the base for overrides.

That works fine if you only search a single search path, but obviously doesn't work very well if you have multiple.

Ideally, we wouldn't need to specify a base directory to OverridesBuilder, but so it is.

The options I see for dealing with this are:

1. Use the working directory, rather than the search directory as the base for the exclude pattern. I believe this is what ripgrep does. I think that probably isn't what most users would expects though.
2. We file an issue and maybe a PR with the ignore crate on the ripgrep repo, and wait for a fix to be merged that either allows OverridesBuilder to be relative to the search dir, or allow passing in multiple Overrides to the WalkerBuilder, so we can add different overrides for different base dirs. (the former would be preferred).
3. Fork the ignore crate, and make changes to make it more suitable for fd. This is something I've been thinking about doing, in particular to add support for absolute paths in ignore rules, and being able to add an option to include paths that were previously excluded. However, that would be committing to a significant amount of work, and is more than I am willing to take on right now.
4. Use a heuristic where if you pass a single path, we use that as the base, but use the working directory, if there are multiple. Possibly, this is even more surprising than 1.
5. Possibly add additional rules using relative paths to the original base directory. This feels hacky, and I'm not sure it would even work.

1 or 4 are the only options that are really viable in the immediate future.

[luckman212]

Thanks for thinking about this @tmccombs. I agree none of these options sound ideal. I do think that no.3 sounds like the correct decision, but I would not ask anyone to take on such a large amount of work.

Question about no.1: if we change the
working directory to / before executing our search, and use --search-path to specify our scope, would that essentially give us "absolute path exclusions"?

If the answer is "yes" then I think that sounds like the least insane option, along with a prominent note in the readme and manpage about this until a real fix is provided upstream.

[tmccombs]

if we change the working directory to / before executing our search, and use --search-path to specify our scope, would that essentially give us "absolute path exclusions"?

yes, but it would have side effects. For example it would also impact the output.