Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Allow config path to be specified via environment variable #89

Closed
HUMORCE opened this issue Aug 27, 2024 · 5 comments
Closed
Labels
enhancement New feature or request

Comments

@HUMORCE
Copy link

HUMORCE commented Aug 27, 2024

I prefer to put the config file in a manageable dir, e.g.: ~/.config/tlrc/config.toml

@acuteenvy
Copy link
Member

tlrc uses the dirs crate, specifically this function to get the default config dir. It supports $XDG_CONFIG_HOME on Linux.
What OS are you on?

Regardless of that, there is a --config command-line option that you can use to override the default path.
Alias tldr to tldr --config path/to/file in your shell if you want to make this permanent.

@acuteenvy acuteenvy added the enhancement New feature or request label Aug 27, 2024
@HUMORCE
Copy link
Author

HUMORCE commented Aug 28, 2024

What OS are you on?

macOS

tlrc uses the dirs crate, specifically this function to get the default config dir.

It specifies different standard user's config paths for different OSs. Many programs use a built-in search order for configs.

e.g.

$HOME\config\name
<XDG_CONFIG_HOME> (environment variable)
<standard_path> (from lib, like dirs crate,etc.)
...
<system_wide>

Regardless of that, there is a --config command-line option that you can use to override the default path.
Alias tldr to tldr --config path/to/file in your shell if you want to make this permanent.

Yes, I am already added it.

@acuteenvy
Copy link
Member

I wanted to try reporting this upstream, but it seems that people have requested this feature multiple times and they keep rejecting every request they get. This has been discussed in dirs-dev/directories-rs#47.

Anyway, it's pretty easy to just do this manually. What about the cache directory? Currently it's ~/Library/Caches on macOS, should it be changed to follow the XDG spec too? I've never used macOS, I don't really know the standards there. What do other command-line programs do? $XDG_CACHE_HOME and $HOME/.cache like on Linux?

@acuteenvy acuteenvy changed the title [Feature Request] Provide environment variable for config path [Feature Request] Follow the XDG base directory specification on macOS Aug 29, 2024
@HUMORCE
Copy link
Author

HUMORCE commented Aug 30, 2024

I wanted to try reporting this upstream, but it seems that people have requested this feature multiple times and they keep rejecting every request they get. This has been discussed in dirs-dev/directories-rs#47.

They should be rejected, there is nothing wrong with choosing OS standard dirs. Many programs store configs to $HOME/.config, just a convention, before the XDG specs, and these programs don't necessarily follow the environment variables of the XDG specs, they are preferring to hardcode the config path.

I don't really know the standards there. What do other command-line programs do? $XDG_CACHE_HOME and $HOME/.cache like on Linux?

Here are two examples, which are also rust programs:

Starship store config in $HOME/.config without a sub-dir (~/.config/starship.toml) (any platforms)

Zoxide store config in OS standard dir just like tlrc.

Both of them can set config path via environment variable.


So I'm just requesting an environment variable of config path, or config path search order.

Request updated.

@HUMORCE HUMORCE changed the title [Feature Request] Follow the XDG base directory specification on macOS [Feature Request] Allow config path to be specified via environment variable Aug 30, 2024
@acuteenvy
Copy link
Member

I added support for an environment variable, TLRC_CONFIG.

I'll still consider using XDG by default on macOS, since I found a lot of similar requests in other repositories. ~/Library/Application Support will still be supported though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants