-
-
Notifications
You must be signed in to change notification settings - Fork 136
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
XDG Base Directory Specification Compliance #250
Comments
If we follow XDG, then dotfiles folder should be somewhere in $XDG_DATA_HOME :
Since XDG_DATA_HOME default value is $HOME/.local/share, it adds two folders to create before getting dotfiles. Does it mean we need a bootstrap option (discussion initialized in #103) to initialize this ? |
There's a bit of a debate to be had as to where dotfiles should go in Either way, we do not need a bootstrap option to initalise this directory. As the specification (linked above) says: If, when attempting to write a file, the destination directory is non-existant an attempt should be made to create it with permission 0700. If the destination directory exists already the permissions should not be changed. The application should be prepared to handle the case where the file could not be written, either because the directory was non-existant and could not be created, or for any other reason. In such case it may chose to present an error message to the user. Then we just add behaviour to create dotfiles in the new location as opposed to the old. Of course, following the specification to create files in these new locations does break backwards compatibility in at least a small way; people whose shell scripts depend on rcm initialising its files in the original directories would break. However, we would ensure that rcm continues to check the old locations, so that a standard user would notice no difference when updating to a compliant version. |
Well, for rcm they are DATA and not CONFIG, that's why I used $XDG_DATA_HOME. And dotfiles folder will be amongst its own target, which is weird :) Currently defaults are:
XDG defaults would be:
Maybe we can add a |
Let's make this work more seamlessly for XDG users. The easiest lift is the original suggestion: look for Once that is in place, an XDG-minded user can set (In the meantime you can get far with the |
I think this is almost right, although we really should incorporate @mat-m's approach of separating config files from data. The logical flow would be as follows: The
The dotfiles directory should be found by:
Using this resolution logic, new users will automatically use the XDG locations since the old default location checks will fail, and it would be backwards-compatible. No XDG-ising required! |
I have a patch in the works for this - I'll submit it when I next have time to polish it up. |
I think it would be insane & confusing to have Generally, +1 for the XDG compliance. |
OK yes, that seems correct. Thank you for catching that. |
I'm sorry for bump, but is there any progress? @eddsalkield |
This change the default of : - ~/.rcrc with ~/.dotfiles to - ~/.config/rcm/rcrc with ~/.local/share/rcm/dotfiles (XDG_xxxx) It's an _hard_ error to have both ~/.rcrc and ~/.config/rcm/rcrc, except for _compatibility_ to keep ~/.rcrc as a link to ~/.config/rcm/rcrc Completes thoughtbot#250
This change the default of : - ~/.rcrc with ~/.dotfiles to - ~/.config/rcm/rcrc with ~/.local/share/rcm/dotfiles (XDG_xxxx) It's an _hard_ error to have both ~/.rcrc and ~/.config/rcm/rcrc, except for _compatibility_ to keep ~/.rcrc as a link to ~/.config/rcm/rcrc Completes thoughtbot#250
Since 2010, the XDG Base Directory Specification has been widely accepted, defining a standard for the locations of user configuration files. Currently, rcm checks by default for the rcrc configuration file in ~/.rcrc, which is not in alignment with the specification.
I propose that the following behaviour be implemented, to locate the default .rcrc file:
This would bring rcm into alignment with the specification, without breaking backwards compatibility.
The text was updated successfully, but these errors were encountered: