Fd: Is there a global configuration file

[jaepetto]

Is there a global configuration file option (.fdrc ?) that can be used to always use the same options?

[sharkdp]

Not yet, no. Certainly could be useful to support that. Until then, you can always set up an alias, e.g. alias fd="fd --no-ignore".

[sharkdp]

I've thought about this again, and I think that I'd like to avoid adding a config file for fd. Using aliases is the better solution as it doesn't affect the way fd behaves in shell scripts.

[kpym]

The problem with aliases is that when you use bash, powershell and cmd at the same time, it is not practical (even not possible in cmd ?). I would like to advocate for the existence of global config file.

For example in ripgrep the config file is set by environment variable, and this is very fast : no need to check multiple locations.

[sharkdp]

Opening for further discussion. I'm not completely opposed to this idea.

[sharkdp]

I thought about this again. I really like the fact that fd will always behave the same, without any side effects caused by environment variables or config files. I use fd in shell scripts a lot and wouldn't like the outcome of these scripts to be influenced by a global config file.

Sure, we could add a --no-config option, but we would need to remember to always use this in shell scripts.

[kpym]

Actually fd do not always behaves the same : if you run it in a folder with .gitignore it will not consider all files. This is the reason why I would like to have configuration file, to have the same behavior anywhere by activating always -I switch by default.

So finally we want the same thing : having the same behavior everywhere. But probably we do not put the same meaning in "the same behavior " ;)

[sharkdp]

I think that's more like saying: fd foo behaves differently in a directory with a foo file than in a directory without a foo file. It's also easy enough to use fd -I in a script if that .gitignore behavior is not wanted.

(you might be interested in #612)

[kpym]

As you see we don't agree (and we can't, because we are different persons not robots ;)) what should be the default behavior. This is why the configuration file is important, to make happy everybody about what the "default" behavior should be.

If you don't want it, you don't use it : just do not put a configuration file in your computer.

Almost all cli have the possibility to use configuration file for this reason, and it was never considered as weakness, as far as I know.

[NightMachinary]

As you see we don't agree (and we can't, because we are different persons not robots ;)) what should be the default behavior. This is why the configuration file is important, to make happy everybody about what the "default" behavior should be.

If you don't want it, you don't use it : just do not put a configuration file in your computer.

Almost all cli have the possibility to use configuration file for this reason, and it was never considered as weakness, as far as I know.

@kpym Perhaps you can write a new language that compiles basic aliases and shell functions into different languages (bash, powershell, etc). This way, you can solve the problem systematically, in a way that scales. I think lots of people will like that.

[NightMachinary]

@kpym Another solution is to create a wrapper using, e.g., python.

[tmccombs]

@kpym consider: if I made a useful program which assumed fd respects .gitignore. then you try to use this tool, but it breaks because of your configuration to ignore .gitignore files. Of course you don't realize that's why it broke so you just think my tool doesn't work. This is why global configuration for cli tools used in scripting is a bad idea. Grep doesn't have a config file, but it did support setting default options with an environment variable. This was later realized to be a mistake, because setting that environment variable could easily break scripts, and use of that environment variable has been deprecated.

[kpym]

@tmccombs Perhaps having a --ignore-config switch will allow you to produce scripts that work everywhere, regardless of local configuration?

This is why global configuration for cli tools used in scripting is a bad idea.

If it were so obvious and consensual probably all cli tools would have done the same. There are pros and cons. The Idea is to make more people happy, IMO ;) The question is how to satisfy those who want a global configuration and those who are afraid that this configuration will break their scripts.

My proposal is to allow global configuration to satisfy the first ones (me included) and to put a switch to ignore this configuration to satisfy the second ones (like you and @sharkdp if I understood well).

[tmccombs]

What other unix-filter style cli tools have configuration files? Afaik, things like find, sed, ls, etc. do not have configuration files.

[kpym]

@tmccombs What other unix-filter style cli tools use .(git|name)ignore ? What other unix-filter style cli tools are supposed to work in all systems with all shells (Windows with powershell et cmd including) ?

And what about rg (ripgrep) ?

[xorander00]

My vote goes for adding something akin to ripgrep's approach with an optional RIPGREP_CONFIG_PATH environment variable.

[sharkdp]

@tmccombs What other unix-filter style cli tools use .(git|name)ignore ?

I think this is not (specifically) related the config file discussion.

Using .gitignore files is a feature of fd that can be enabled or disabled. It can change the search results.

Imagine find would have a config file where users could configure whether or not a find -name "…" search would be case sensitive or not. Script authors could not rely on either of these behaviors as they would not know the user setting. Instead, find does not provide a config file and has find -name and find -iname.

Things that might be okay to be configurable would be settings that do not change the search results. Like whether or not you want fd to show colorized output. Or maybe how many threads you want to use for a search.

[kpym]

Script authors could not rely on either of these behaviors as they would not know the user setting. Instead, find does not provide a config file and has find -name and find -iname.

@sharkdp As already pointed heaving --ignore-config switch overcome the script reliability.

Adding a flag in a script is not so much efforts compared to adding a flag every time we type fd in a shell. This is my main argument for heaving config file : the behavior of the default parameters allows to type less in shells, just laziness ;)

[sharkdp]

Adding a flag in a script is not so much efforts compared to adding a flag every time we type fd in a shell.

Well, that's what aliases are for.

The problem with aliases is that when you use bash, powershell and cmd at the same time, it is not practical (even not possible in cmd ?). I would like to advocate for the existence of global config file.

Ok, serious question. I'm not a Windows user. Why are people still using cmd if powershell is out there? And why would anyone use both at the same time?

If cmd is out of the picture, how hard is it really to set two aliases (for two different shells on two completely different operating systems)?

[ptzz]

One issue with aliases that I ran into recently is that they don’t play well with xargs. I.e. foocmd | xargs fd foo does not use any existing fd alias.

[BurntSushi]

FWIW, I basically had the same stance as @sharkdp here before I gave in and added config file support to ripgrep. I found the environment variable solution to be nice because it requires someone to explicitly set it and doesn't require needing to know anything about platform specific config files. The user just gets to choose, full stop.

I think Windows was my primary motivation because there are weird aspects about creating aliases on Windows, although those things might impact ripgrep more severely than fd. And then of course there are circumstances where aliases can't be used (or can't be used easily). Although, my stance there was to just create a wrapper script and drop it into ~/bin.

IMO, there is some good motivation for a config file largely not because there are work-arounds, but because users find it convenient. But I also think it's justifiable to resist adding the complexity. As others have mentioned, there are real downsides to config files, particularly when fd is used in a script.

[StaticPH]

IMO, there is some good motivation for a config file largely not because there are work-arounds, but because users find it convenient. But I also think it's justifiable to resist adding the complexity. As others have mentioned, there are real downsides to config files, particularly when fd is used in a script.

Just putting in my two cents; I'm in favor of an environment-variable-controlled config, though I don't personally think it will be as useful for fd as it currently stands. With a program like ripgrep especially, which allows you to add additional custom filtering options, the major advantage of allowing a config file (at least from my point of view) is in avoiding things like this:

Behold, and grimace at the cringe-inducing alias from before ripgrep supported a config file :grimacing:

_{Yes, it could have at least been a function or a wrapper script, but it wasn't because I didn't want to remember to explicitly call the original executable every time I used it in a shell script}

_{Yes, many of those file types would be classified as binary data, and not searched by default, but I had my reasons for adding them anyways. I don't remember what those reasons were, but I very clearly remember having had them!}