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

Does anyone actually change their XDG variables? #1250

Open
LukeSmithxyz opened this issue Jan 16, 2023 · 8 comments
Open

Does anyone actually change their XDG variables? #1250

LukeSmithxyz opened this issue Jan 16, 2023 · 8 comments

Comments

@LukeSmithxyz
Copy link
Owner

In a bunch of files in this repo, filenames are hyper-redundantly specified with XDG variables, e.g.:

${XDG_CONFIG_HOME:-$HOME/.config}/nvim/init.vim

instead of just:

~/.config/nvim/init.vim

Obviously, this is so someone change change their XDG_CONFIG_HOME. It also specified a fallback location if the variable is not set at all, although it is set in the zprofile file here, but I wanted generalizability of files if they are taken to other systems.

The issue is (a) I suspect nearly no one ever does this or changes XDG variables and (b) it looks ugly. (b) is a highly legitimate concern as if it serves no function, it causes a lot of confusion in a system that is supposed to be easy for newcomings to play with, expand and modify. This has also caused issues in PRs.

Keep in mind I am rigidly adherent to XDG directory specifications as even the presence of symlinks in home can attest, so I'm not saying any file will move, but the issue is whether I should preprogram all this for a funcionality that is probably not used.

So does anyone actually change their config or cache, etc. directories or should I just remove this sillyness and have easier to read and edit files?

@juliapaci
Copy link
Contributor

If anyone does bother to change them then im sure they are able to switch some hard coded directories with ones that include xdg variables and its likely that they use xdg alot anyways so it wont be as much as an annoyance to change every directory.

@gokberkgunes
Copy link

gokberkgunes commented Jan 20, 2023

I change the XDG variables. I follow Earnestly's .local convention as the convention explained here. The idea is to set XDG variables how directories are arranged in /usr/local/. Basically, everything is structured under ~/.local/. There is only one dot file, .local, exists under the home directory, and this convention provides even cleaner home directory.

export XDG_DATA_HOME="$HOME/.local/share/"
export XDG_CONFIG_HOME="$HOME/.local/etc/"
export XDG_CACHE_HOME="$HOME/.local/var/cache/"
export XDG_STATE_HOME="$HOME/.local/var/state/"

All in all, even if there are people like me who change their XDG directories, they should be knowledgeable enough to reflect this change to their configuration files. It is better to remove redundancy and confusion. I agree with the removal of the silliness.

@port19x
Copy link

port19x commented Jan 24, 2023

Yeah remove the sillyness. If you're gonna set differing XDG directories, you probably either have your own config or know how to adapt one

@LalleSX
Copy link
Contributor

LalleSX commented Feb 9, 2023

export XDG_CONFIG_HOME="$HOME/.local/etc/"

If you do this you are insane.
It doesn't clean your home folder, the dot in .config does that

Anyways...

Yes I do edit it so it has non capitalized letters and shorter words. like code below

XDG_DESKTOP_DIR="$HOME/"
XDG_DOWNLOAD_DIR="$HOME/down"
XDG_TEMPLATES_DIR="$HOME/temp"
XDG_PUBLICSHARE_DIR="$HOME/pub"
XDG_DOCUMENTS_DIR="$HOME/dox"
XDG_MUSIC_DIR="$HOME/music"
XDG_PICTURES_DIR="$HOME/pix"
XDG_VIDEOS_DIR="$HOME/vids"

@HelionSmoker
Copy link
Contributor

Yes I do edit it so it has non capitalized letters and shorter words. like code below

May I ask what is the point of this? There is a special script ~/.local/bin/shortcuts that accomplishes the same thing. in the interactive shell. In scripts, just use your full path to the directory.


As for my usage, I haven't and probably will not change my XDG variables for the foreseeable future.

@ghost
Copy link

ghost commented Feb 26, 2023

I guess the whole point of XDG is allowing people to change it, but it's not particularly practical because there will always exist dissenting software, so we'll all be using XDG_CONFIG_HOME="$HOME/.config" on account of stubborn developers (unrelated but I'm sure we all have our woes with openssh for hardcoding ~/.ssh).

In a ideal world, one could store all user-specific system files in ~/.xdg (i.e: ~/.xdg/config,~/.xdg/local, etc) rather than the tripartite organisation that is currently in effect in which case it would make sense to employ ${XDG_CONFIG_HOME:-$HOME/.config}/nvim/init.vim, though I doubt I will ever live to see such a day.

I strive towards this utopia - and so should everyone else, for my sake(!)

Regarding the advanced-user argument, I'd say that robustness rules redundancy, and making your code work universally with the least hassle is more important than saving a few characters in shell scripts. Likewise, perhaps for an intermediate user who is just downloading random scripts off GitHub (not referring to this repo, but to others), having to look through the code to make it work with their config could make them reconsider whether running the script is a good idea, and it forces auditing from the user. This pessioptimistic view merely justifies an inconvenience, however, and in my opinion - regardless of readability - we still ought to strictly, rigidly and fully adhere to XDG in our scripts.

@guitarman513
Copy link

I don't change my XDG vars, but as someone who learned a lot from channels such as Luke's, seeing them written in configs helped me learn even more and dive deeper down rabbit holes such as XDG specs. But idrc what you do, I agree retyping that stuff over and over again is pretty retarded if nobody relies on it.

@speedie1337
Copy link

I think a good compromise for code quality is to simply do something like CONFDIR="${XDG_CONFIG_HOME:-~/.config}" at the top.

This way, the scripts are still easy to read, and the few people who change their variable can continue to use it.

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

No branches or pull requests

8 participants