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 / Idea]: Use XDG Base Directory Specification by default #65

Open
jtrv opened this issue Nov 23, 2022 · 4 comments · May be fixed by #76
Open

[Feature Request / Idea]: Use XDG Base Directory Specification by default #65

jtrv opened this issue Nov 23, 2022 · 4 comments · May be fixed by #76
Labels
enhancement New feature or request

Comments

@jtrv
Copy link

jtrv commented Nov 23, 2022

Suggestion / Feature Request

The shellclear/ and .shellclear/ directories unnecessarily pollute users' home directory.

The XDGBDS defines where these files should be placed with environment variables in order to avoid this.

The XDG Base Directory Specification is based on the following concepts:

  • There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.

  • There is a single base directory relative to which user-specific configuration files should be written. This directory is defined by the environment variable $XDG_CONFIG_HOME.

  • There is a single base directory relative to which user-specific state data should be written. This directory is defined by the environment variable $XDG_STATE_HOME.

  • There is a single base directory relative to which user-specific executable files may be written.

  • There is a set of preference ordered base directories relative to which data files should be searched. This set of directories is defined by the environment variable $XDG_DATA_DIRS.

  • There is a set of preference ordered base directories relative to which configuration files should be searched. This set of directories is defined by the environment variable $XDG_CONFIG_DIRS.

  • There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME.

  • There is a single base directory relative to which user-specific runtime files and other file objects should be placed. This directory is defined by the environment variable $XDG_RUNTIME_DIR.

All paths set in these environment variables must be absolute. If an implementation encounters a relative path in any of these variables it should consider the path invalid and ignore it.

@jtrv jtrv added the enhancement New feature or request label Nov 23, 2022
@kaplanelad
Copy link
Member

Hey @JacobTravers, thanks for reporting this issue.

Just to make sure that i understand, you suggestion is to manage the .shellclear in $XDG_CACHE_HOME instead of $HOME ?

@jtrv
Copy link
Author

jtrv commented Dec 12, 2022

Correct, so it should check first if $XDG_CACHE_HOME exists, if so it would use $XDG_CACHE_HOME/shellclear and if not it would fall back to .shellclear.

As for shellclear/, I might be mistaken but I believe there was an empty shellclear/ directory created in $HOME when I installed this with cargo install --git, but I'm not sure what data would have been there or how it would fit into the XDGBDS. It may have been a typo.

@boaz-quotient
Copy link
Contributor

@kaplanelad can i work on it?

@kaplanelad
Copy link
Member

kaplanelad commented Dec 13, 2022

Sure @boaz-quotient Thank you.
i'm using dirs crates. in this lib you have the function config_dir that already taking the $XDG_CONFIG_HOME with a default.

Please note that we need to support the old version, which means if the user already has the config file in $HOME path, we need to take it first

Thanks again

@boaz-quotient boaz-quotient linked a pull request Apr 7, 2023 that will close this issue
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

Successfully merging a pull request may close this issue.

3 participants