feature request: allow specifying multiple search paths

[rfourquet]

I.e. fd [pattern] [path [path ...]]. I don't foresee a need to specify a 3rd argument to fd which would not be a search path, so allowing multiple paths seems harmless and useful. Also, by compatibility with find, would there be a problem to not error if the provided paths are files (i.e. not directories)?

[rfourquet]

For example, here is my today's use case: I'm looking for the presence of a certain .so library file in the dropbox versions present on my nixos system; I would like to simply do:
fd libGL.so.1 /nix/store/*dropbox*.
In particular it would be useful that the files in the paths list (expanded from *dropbox*) do not generate errors.

[for-coursera]

Second that request. Passing a listing collected by fd from several directories to fzf would be extremely handy. ripgrep already manages that, but fd is faster, isn't it? :)

[Doxterpepper]

@sharkdp, mind if I take this on?

[sharkdp]

@Doxterpepper That'd be great!

[ChengCat]

I'm not sure whether this is a good idea. If /nix/store/*dropbox* expands to an empty string, you could be surprised, as fd will be searching inside the current directory. One could assume fd pattern (empty path list) to mean no path searched, but it contradicts with the current design.

BTW, NixOS use symlinks extensively, so you might need -L sometimes. (#180)

[rfourquet]

This is probably a matter of pragmatism.

If /nix/store/*dropbox* expands to an empty string, you could be surprised,

You are right, but I needed this on the command line, after knowing that the expansion is not empty. Then the alternative I had to resort to was no better in this respect (I don't remember if I used find directly, or fd with a loop over). fd with multiple paths would simply have been more convenient.

[ChengCat]

This is a matter of design, and the intention is to reduce potential surprises or pitfalls. It is especially important for a tool intended to replace a fundamental utility like find. I understand that it is convenient for this particular use case, but you probably agree that, every time you write fd pattern pathWith* in a shell script, you need to consider that pathWith* could possibly expand to an empty string.

I'd suggest a new syntax for this: fd pattern -. This reads stdin for a path list to be searched.

[Doxterpepper]

@ChengCat, I don't think "expanding to an empty string" is a thing. I'm pretty sure wildcards are handled by your shell and give an "Error: *foo* is not a directory" if the wildcard expression does not match anything.

At least that's what I see in bash. I don't know how other shells might handle wildcards but I imagine they're all similar.

[sharkdp]

@Doxterpepper exactly. The shell will either immediately thrown an error:

zsh> echo drop*
zsh: no matches found: drop*

or just leave the wildcard as is:

bash> echo drop*
drop*

In the second case, we are also fine since 'drop*' does not exist as a directory, so fd will throw an error.

[ChengCat]

I confirm that my fish shell also throws out an error.

I didn't know about this, thanks for pointing this out.

[sharkdp]

Closed via #182