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. 👍

[PThorpe92]

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

[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 support for theme.yml file #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 😅

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 👍
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.

[WieeRd]

I would also appreciate a method to set default command line flags without using aliases.

Besides providing a uniform settings across different shells, this will also make supplying eza as a previewer to different apps much easier. I've been integrating eza with fzf, TUI file explorers, and many other terminal apps recently, and I had to copy-paste a long, long string of eza flags to aliases for each tool. With config file support, I can place the default flags in the config and fzf --preview=eza will just work.

Perhaps we can leave the current YAML config for theming only, and support a eza.conf text file that just holds command line flags with comment support. It'll be much easier to implement, since simply filtering the commented lines and prepending the default flags before parsing the CLI flags would suffice.

rg and bat does exactly this.
https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md#configuration-file
https://github.com/sharkdp/bat?tab=readme-ov-file#format

[gierens]

Yeah, the current file is called theme.yml because it's only intended for theming ... the original plan was to add an additional config.yml or something for more general options.

YAML has comment support, so that wouldn't be a reason to not continue using YAML for that file as well. Or do you see one?

[cafkafk]

rg and bat does exactly this.

I'm not sure I see the benefit here to this approach over a regular shell alias, specially considering an alias does exactly this already. I feel like it goes against separation of concerns to essentially create an eza'ism for making what's essentially an alias, while for the yaml approach on the other hand, it supports more verbose and explicit configuration than can be achieved with just arguments, and also gives structure and readability benefits. And also, allows for potentially more advanced configuration than is unreasonable to implement as just flags.

this will also make supplying eza as a previewer to different apps much easier. I've been integrating eza with fzf, TUI file explorers, and many other terminal apps recently, and I had to copy-paste a long, long string of eza flags to aliases for each tool.

In cases like this, it may make more sense to just create a wrapping shell script that is invoked instead of eza directly. Also, it's likely that different tools will require different settings.

---

I also may be overlooking something here, so I'm also really interested in hearing if you don't see it the same way.

[anuramat]

I have this line in my bashrc:

export EZACMD="eza --group-directories-first --group --header --git --color=always --icons=always --color-scale=all --sort=time"

and then I reference it across 3 other scripts. it's not the end of the world, but it's kinda ugly. I don't see a reason NOT to have (at least) a stupid simple implementation equivalent to:

eza $(cat "$XDG_CONFIG_HOME/eza/config" 2>/dev/null || ...)

especially considering there's already a file for themes and an $EZA_CONFIG_DIR

[mlopezgva]

I don't see a reason NOT to have (at least) a stupid simple implementation equivalent to:

eza $(cat "$XDG_CONFIG_HOME/eza/config" 2>/dev/null || ...)

especially considering there's already a file for themes and an $EZA_CONFIG_DIR

I agree.
Having no config file yet, I would suggest something a bit different (not that it doesn't exist, but certainly uncommon for "system apps"):

default:
    # system or user-wide defaults, like, grouping, sort by extension etc.
    group_directories: first
    sort: [extension,date]
    long: true
    icons: auto
    color: auto
   # etc.

extra:    # just a "working" name :-p
    fzf:
        # --group --header --git --color=always --icons=always --color-scale=all --sort=time"
        group: true
        header: true
        git: true
        color: always
        icons: always
        color_scale: all # or colorScale, whatever suits you :-)
        sort: time        # overrides 'default'
    short:
        default: false    # like, do not cascade from 'default'
        icons: auto       # overrides 'default'
        sort: extension
        oneline: true
     ls:
        default: false
        # settings to mimic ls
     lsd:
        inherit: ls
        # settings to mimic lsd but using 'ls' as base, including the default: false

etc.

The default group would be the one used when invoking eza without parameters. The "extra" groups would be what we use to use with aliases, but since aliases are not always accessible, this would allow to have different configurations. And they would inherit 'default' and add (or override) their own flags. Or having an option to NOT inherit 'default'. Or even an 'inherit' to get another one (like lsd would do, using ls flags as initial point).
To use them, something simple like eza -c fzf or eza --extra=short to use the different configurations.
Being YAML, includes can be used to keep different configurations separated, if needed / desired.

@cafkafk
In cases like this, it may make more sense to just create a wrapping shell script that is invoked instead of eza directly.
Also, it's likely that different tools will require different settings.

This approach allows having a lot of visualization and filters options "named" and easily accessible, and also easy to maintain (they would be in the configuration directory).

[CouldBeThis]

One problem I am encountering these days with shell aliases is that as new features are added to eza and incorporated into my aliases, that then breaks in older versions of eza.

Because the repo-packaged version of eza varies from system to system, but I like to share my shell aliases. But eza chokes on unknown argument/option.

Hopefully a configuration file would have integrated from the outset some kind of no-fail mode whereby you could tell it to ignore unknown options, in anticipation of future changes.

I wish I knew how to program so I could just implement the config file, instead of adding to this already very long thread.

[anuramat]

@CouldBeThis maybe something like this would work in the meantime?

export EZA_CMD='eza --old_feature'

declare -A versions
versions=(
  ["--feature1"]=0.1.2
  ["--feature2"]=0.2.3
  ["--feature3"]=0.20.30
  ["--feature4"]=0.20.40
)
for feat in "${!versions[@]}"; do
  eza --version | sed -n 's/^v\(\S*\)\s\S*$/\1/p' | xargs printf "%s\n${versions[$feat]}\n" | sort -VCr && EZA_CMD+=" $feat"
done

alias ls="$EZA_CMD"