Config file?

[Omnikron13]

I think there should really be a config file for this, to set up various defaults and such. Even the colours and what have you that can be tweaked with environment variables, it seems it would surely be better to really have in a config file doesn't it?

I've hacked my way to getting it to behave how I'd like with fish abbreviations and such like, but it seeems weirdly missing like $XDG_CONFIG_HOME/eza.conf (or perhaps even a folder under $XDG_CONFIG_HOME if people might want to have colour/icon themes and such?)

Shouldn't really be that tricky to implement imo, it's more what kind of file format, what options, etc. people would favour?

[PThorpe92]

This is currently a work in progress, with the first step (a theme.yml file replacing the EXA_COLORS environment variable) PR just being hung up on testing issues.

This is technically a duplicate of #139 but I'll leave it open for discussion on what everyone would like to see feature wise for the eventual config file and ideally so we can get a few theme contributions. I'd really like to be able to offer a handful of pre-made themes to choose from when #840 can get merged. :+1:

[PThorpe92]

Looks like this will get merged here pretty soon, and with custom icon support both thanks to @gierens :rocket: :rocket:

[CouldBeThis]

I wanted a config file for ages to replace my collection of long shell aliases. A couple of times went looking around in the documentation, repo, online etc trying to find out how to do it.

@PThorpe92 I see #840 which from what I can see is mostly about colors, with an eye to expanding later. I will patiently wait/hope for all the options to be included eventually. And appreciating eza and contributors meanwhile.

I read #139 and while initially wasn't sure if there is really a benefit to config file vs shell alias I found it convincing that there is. Personally I just find things easier to read with linebreaks, comments and divided up into multiple files. Since opinions were solicited here:

• I saw formats yaml and toml mentioned and #840 is using yaml. Just please don't make is json or some other format that doesn't allow for commenting.

• Loading a specific config file when running would be great. e.g. eza -c ~/.config/eza/alternateconfig.yaml

  • With arguments/config files having clear order of precedents. I think left-to-right is standard

• I personally find it really helpful when cli tool facilitate the creation of a config file

  • My feeling for eza is that generating one by an argument on request is probably better than dropping one in the $XDG_CONFIG_HOME or some system directory by default at install time. Because it is having a lot of development. And I have seen before where there is some sort of compatibility issue between config files for different versions.
  • Come to think of it (and maybe someone else already did), I wonder if it would make sense to consider different versions and future addition/removal/change of features? You don't want eza to die because you bring your dotfiles in from a different system that is a few versions ahead and the config file has something the current version doesn't recognize. Perhaps it would be best to silently skip any unrecognized entries unless a strict/verbose mode is requested by the user? Which I guess could be either via the cli or in the config file itself.
  • Opinions differ, but my preference is that either by default, or on the website, or somewhere, there is a config file available with all/most of the available options rather than just a few. Easier to delete than search around copy/pasting.
  • Opinions differ, but my preference is that the default config has comments explaining whatever options it does include so you don't have to spend time cross referencing a different document.
  • Both the above subject to maintainability. It would be tedious for the devs to have to manually update with each release.

[Omnikron13]

• I personally find it really helpful when cli tool facilitate the creation of a config file

In the hobby project I've been mucking around with lately, I'm going with a strategy of embedding a commented YAML config file as the source of default values. You can then just handle that the same way as the rest of the config file hierarchy, it centralises the default configuration, users can easily find it in one place in the project repo, and you can very easily add a few lines of code that will spit a copy out for end users.

[PThorpe92]

@CouldBeThis

Awesome, those are all helpful points!

I believe we will be sticking with yaml. I personally cannot stand JSON for a configuration language, I deal with too much of it at work as it is :sweat_smile:

I also think it's a good idea to be able to load a specific config as a command line argument, and I'd like to have another one that dumps the default config to stdout or a specified location. And I agree the default one should include good comments :+1: I don't really like dumping one at XDG_HOME | XDG_CONFIG, but I think its reasonable to check there for an existing one (if EZA_CONFIG_DIR isn't set, before falling back to the normal configuration previously done from ENV variables.

[kfernandez31]

Hello, what's the current status of this?

[Omnikron13]

I don't really like dumping one at XDG_HOME | XDG_CONFIG, but I think its reasonable to check there for an existing one (if EZA_CONFIG_DIR isn't set, before falling back to the normal configuration previously done from ENV variables.

I'm never 100% sure I've grasped it all properly, but I believe according to the Filesystem Hierarchy Specification a file of the defaults should probably go in /usr/share/ (static supplementary files; /usr/ is 'read-only' and so to be supplied by a package or the distro, /usr/share/ for architecture independent files for which default config would generally fall into IME).

Can't say I've written enough thing warranting proper config hierarchy kinda stuff to have really followed this, but as a rule I'd say the de facto 'correct' hierarchy would be something like this:

1. /usr/share/ - default config from the upstream source of the software.
2. /etc/ - systemwide configuration from the packagers of the distro.
3. /etc/[...].d/ - administrator modifications to the systemwide config.
4. $XDG_CONFIG_HOME/[...]/ - user specific modifications to the config
5. $XDG_CONFIG_HOME/[...].d - user specific modifications for the specific system. (This is maybe a little shakier, and only really worth considering for certain software where a user is likely to need to tweak their dotfiles per system IMO, or for general completeness in case users might want to for unforseen reasons)
6. Environment variables - tweaks for a specific shell, script, or session.
7. Flags - very specific tweaks for a single invocation.

[gierens]

Hello, what's the current status of this?

840 is awaiting review from @cafkafk

[finite-state-machine]

It looks like it's been merged! 🎉

Since I don't speak rust, and since there appear to be no automated tests or sample config files, I have no idea how to use this.

Do we know when some documentation (or anything that would serve as documentation) might be added?

[finite-state-machine]

Looking through the code a bit more closely, it doesn't look like there's a way to specify defaults for most command-line flags yet. 🙁

[gierens]

There is a sample config under docs/theme.yml in the repository and there is also some documentation in the README. And yes you are correct, at the moment it only concerns theming. Configuring icons and styling via a file has been one of the most requested features and that's why we gave that priority for our initial implementation, which still turned out to be a fairly heavy PR. Expanding it to all settings is just going to take more time. Sorry.

[finite-state-machine]

@gierens Thanks for the clarification! I appreciate the wonderful tool you and the other maintainers have built, and appreciate everything you do to improve it!

[PThorpe92]

This actually brings up a good question.

When adding an actual configuration file instead of just a theme file, is that a place for specifying a default command line argument, considering the ubiquity of shell aliases? If not, what options do we have in the config file?

[gierens]

Hm, I don't really see these options as mutually exclusive to be honest. One can specify defaults via the configuration file and use or overwrite those in the shell aliases.