--exclude is not working

[UnknownSuperficialNight]

What version of fd are you using?
[paste the output of fd --version here]

version='fd 8.4.0'

im having issues with syntax or fd is just broken

fd --exclude "/mnt/1.9tbhdd/SteamLibrary" --exclude "/mnt/1.9tbhdd/Back In Time Snapshots" -t f -e mkv -e mp4 --search-path '/mnt/1.9tbhdd' -x bash -c 'echo {}'

the above command will search for files with the extensions .mkv and .mp4 within the directory /mnt/1.9tbhdd, while excluding the two specified directories (/mnt/1.9tbhdd/SteamLibrary and /mnt/1.9tbhdd/Back In Time Snapshots).

The bash -c 'echo {}' is just a example before anyone comments u don't need it it's just here for context

problem im having is /mnt/1.9tbhdd/SteamLibrary is still being found even with the --exclude

i tried ! -path 'Dir' instead of --exclude 'Dir' that wont work with --search-path so i tried --full-path and that does nothing just exits the program

any ideas on what im doing wrong?

[tavianator]

--exclude is relative to the starting directory, as if it's a .gitignore rule basically. So this should work:

$ fd --exclude /SteamLibrary --exclude "/Back In Time Snapshots" ... /mnt/1.9tbhdd ...

[IzhakJakov]

How do you do exclude any directory matching pattern?

e.g: exclude any dir named templates?
I tried fd -E '*/templates/*' but that only worked on the top level (relative) dirs and not recursive

[tmccombs]

Just use "templates/"

[axelsimon]

It is a bit strange that passing an absolute path to fd to exclude doesn't work, as it still interprets it as relative.

Running the following from $HOME:
fd -E ~/src/NixOS/nixpkgs terra --> shows lots of results in ~/src/NixOS/nixpkgs
fd -E src/NixOS/nixpkgs terra --> doesn't show results in ~/src/NixOS/nixpkgs

Furthermore, if the exclude flag is always relative, then how is one supposed to use ~/.confg/fd/ignore?

[tmccombs]

So fd's concept of ignore/exclude comes from how .gitignore files work. In git, it doesn't really make sense to use absolute paths in ignore files, because such paths wouldn't be portable when a git repo is used on a different host, and the root of the git repo serves as the base for the ignore rules.

fd (and ripgrep) inherit that behavior, but use the current working directory as the root instead of the git repo root. But that can lead to some weird behaviors (and bugs). However, at this point, making it so ignore rules that start with / are treated as absolute paths instead of relative to the working directory would be a breaking change. Maybe we could support some other syntax for that, but it would be difficult to do so unless it was implemented in the upstream ignore library (part of ripgrep) that we use, or we forked that project (which would be a substantial amount of effort).

In your case would ignoring nixpkgs work?

[jeff-hykin]

I think part of the confusion is: does --exclude mean --exclude-dir, --exclude-match, or --ignore.

I, and seemingly others would expect --exclude to mean --exclude-dir(s). Ideally with globbing, but at least for local paths and absolute paths.

For example, this feels broken to me:

fd octave . --exclude './.vscode/'
...
./.vscode/extensions/toasty-technologies.octave-0.0.3/package.json
...

I would expect '.vscode', './.vscode', './.vscode/*' to all result in the same exclusion. E.g. first expansion, then make every path an absolute path (.vscode becomes $PWD/.vscode) then add all those absolute paths to the exclude list.

Personally, if I wanted it to be more like gitignore (any depth exclude) I would just use | grep -v

It would be nice to have an --exclude-dirs (splat/path based)

[tmccombs]

I, and #1609 would expect --exclude to mean --exclude-dir(s). Ideally with globbing, but at least for local paths and absolute paths.

It does support globbing, and local paths. But it specifcally uses gitignore syntax. It's equivalent to having a line in your global ignore file, and it treats the current working directory as the root.

So for your example, you would need to use /.vscode or /.vscode/* (although those have slightly different behaviors, the former will skip searching the .vscode directory altogether).

Personally, if I wanted it to be more like gitignore (any depth exclude) I would just use | grep -v

The advantage of fd doing the ignore, is that it avoids traversing ignored folders. So for example, if you had thousands of files in your .vscode folder, fd wouldn't have to waste effort searching through all of them.

It would be nice to have an --exclude-dirs (splat/path based)

I'm not necessarily opposed to that, but what would the behavior of that be? How would it be different from --exclude? And how would we avoid confusing users about what those differences are?

[jeff-hykin]

what would the behavior of that be?

Two differences:

1. The following wouldn't happen (it would exclude the .vscode result)

fd octave . --exclude-dir "$HOME/.vscode/"
...
./.vscode/extensions/toasty-technologies.octave-0.0.3/package.json
...

2. The following would happen:

fd octave . --exclude-dir '.vscode/'
...
./octave/.vscode/compatibility_layer/octave_config.init
...

(It would keep the result despite it having ".vscode/" in the name.)

specifcally uses gitignore syntax.

I am very glad it uses a consistent, powerful, well known syntax. That said, I dont think people expect it by default, and its not terribly convenient when I have a list of the absolute paths I always want to ignore, like /nix/store, and I'm changing dirs a lot. I think git ignore works cause it ignores relative to the project path rather than PWD.

[sergeevabc]

$ ver && fd --version
Microsoft Windows [Version 6.1.7601]
fd 10.2.0

$ fd --type d
2025-03-13 W11 a\
2025-03-14 W11 b\
2025-03-16 W11 c\
2025-03-20 W12 d\
2025-03-24 W13 e\
2025-03-24 W13 f\
2025-03-27 W13 g\

It is easy to find only W13-related folders…

$ fd --type d W13
2025-03-24 W13 e\
2025-03-24 W13 f\
2025-03-27 W13 g\

But to find all folders excluding W13-related… Something goes wrong.

$ fd --type d -E W13
2025-03-13 W11 a\
2025-03-14 W11 b\
2025-03-16 W11 c\
2025-03-20 W12 d\
2025-03-24 W13 e\
2025-03-24 W13 f\
2025-03-27 W13 g\

Because I expected to get

2025-03-13 W11 a\
2025-03-14 W11 b\
2025-03-16 W11 c\
2025-03-20 W12 d\

Why oh why, huh?

[tmccombs]

-E W13 means "exclude all files (including directories) named exactly 'W13'". To get what you want you would use -E '*W13*'

[sergeevabc]

@tmccombs, thank you, it works as you suggested, I'll remember that. However, it is a bit confusing that -E has own logic (inherited, I guess, from messy find behavior): user has to add asterisks instead of using some not/negative/invert switch only as we do with other command-line tools. For example:

$ grep foo && grep -v foo

$ cat file.md | awk "/foo/" && cat file.md | awk "/!foo/"

[tmccombs]

-E has own logic (inherited, I guess, from messy find behavior)

As mentioned before in this thread, -E uses the same syntax as .gitignore/.ignore/.fdignore. It is basically a way to add an additional ignore line from the command line.

For ignoring based on a regex, see #198