Show/search hidden files by default (or not)?

[sharkdp]

Possible options are [updated on 2017-06-05]:

• Add a convenient short option for --hidden (-h is for --help ...)

=> Done already, -H can be used (alongside --hidden) for searching hidden directories.

• Add a config file (~/.config/fdrc) where defaults (such as search_hidden=true) can be set

=> As discussed below, this will not be implemented for now. Aliases (such as alias fd="fd -HI").

• Add a status line below the search results to indicate that files were found in hidden/ignored directories (suggestion by @chrivers below).

[chrivers]

From my point of view, there are fundamentally 2 different routes to take here.

Either "fd" is targeted as a system tool (like "find"), or it is targeted as an end-user utility. Think of the "plumbing/porcelain" split i git.

User tools can have config files, but system tools absolutely cannot. If this is going to be used in scripts, in automation, etc, the behavior has to be completely determined from the command line arguments.

Users can still set options via aliases, but I agree that this is less ergonomic than a config file. It's also possible to make a heuristic for determining when to use the config file (say, when the tool is run interactively), but I'm afraid this is too confusing and subtle.

So, if we discuss "fd" as a user tool, it can have all the fancy bells and whistles. Strictly personally, I would love a neater alternative to interactive uses of "find", but I absolutely need to trust that my file finder doesn't hide files from me. For example, a reasonable default could be collapse-vcs, which would turn this:

./Cargo.toml.orig
./Cargo.toml~
./.git
./.git/description
./.git/info
...[thousands of lines]...
./.git/modules/duranium/ORIG_HEAD
./.git/modules/duranium/COMMIT_EDITMSG
./.git/ORIG_HEAD
./.git/COMMIT_EDITMSG
./rustfmt.toml
./examples
./examples/foo.rs

Into this:

./Cargo.toml.orig
./Cargo.toml~
./.git [*]
./rustfmt.toml
./examples
./examples/foo.rs

Or some other syntax - but I'm not very fond of hiding files completely by default.

[sharkdp]

Thank you for the feedback!

From my point of view, there are fundamentally 2 different routes to take here.

Either "fd" is targeted as a system tool (like "find"), or it is targeted as an end-user utility. Think of the "plumbing/porcelain" split i git.

I definitely see fd in the end-user utility corner. It is meant as a "neater alternative to interactive uses of find", as you wrote below.

User tools can have config files, but system tools absolutely cannot. If this is going to be used in scripts, in automation, etc, the behavior has to be completely determined from the command line arguments.
Users can still set options via aliases, but I agree that this is less ergonomic than a config file.

Yes, good points. Maybe, even if fd is not primarily meant as a system tool, we should try to avoid a config file at first. Aliases are not that bad and it's easy to reset them (\fd). They also won't affect shell scripts, as you said.

It's also possible to make a heuristic for determining when to use the config file (say, when the tool is run interactively), but I'm afraid this is too confusing and subtle.

I also believe this would be confusing.

So, if we discuss "fd" as a user tool, it can have all the fancy bells and whistles. Strictly personally, I would love a neater alternative to interactive uses of "find", but I absolutely need to trust that my file finder doesn't hide files from me.

I'm not sure... I believe I have to disagree here. Hidden files are typically hidden for a good reason: because you usually do not want to care about them. ls does not show them, by default. ag does not search them, by default. Shell globs (*) do not include them.

find always searches hidden directories and files, but I believe I like the ignore-by-default option better.

For example, a reasonable default could be collapse-vcs [...]

That's a neat idea, but sometimes I might want to pipe the output of fd to some other program (vim $(fd html)), so this would definitely only be enabled during "interactive use".

[chrivers]

I've thought a bit about it, and I mostly agree. I find myself needing to be sure I see 100% of the available files quite often, so I'll keep using find for that purpose.

I think fd could be a nice complement to rg, in that it has some reasonable opinions that make it easy to use out of the box. How about, in interactive mode only, a status line? Like "$x files found in $y dirs, $z ignored". Then it would be obvious if files are skipped, which is what is the important part here, imho.

It would be great if the status line could give a condensed breakdown of files found, links followed, dirs read, etc. It'd be very useful for getting the "vitals" of a search operation.

[sharkdp]

That's a very neat idea! I'll look into this when I'm back home. Thanks!

[sharkdp]

I have re-considered this. Adding such a status line would always mean that we have to traverse all hidden paths and all ignored paths (and their children, ..), which can lead to huge performance downsides.

I'm closing this for now, but I'm still open to suggestions.

Thank you for the feedback!

[ChengCat]

Sorry, but I am expecting fd to be a system utility. I get this expectation from the description "A simple, fast and user-friendly alternative to find". If you intend this tool to be used interactively only, maybe you should make it more clear.

[sharkdp]

@ChengCat If you see a potential problem with the current situation, please feel free to open a new ticket. In my view, there is no reason not to use fd as a system utility.