Live data from Hacker News

Use the XDG Base Directory Specification

xdgbasedirectoryspecification.com

11–20 of 214 posts

Re: Use the XDG Base Directory Specification

#11
post #6
post #4

Earlier quoted context omitted.

The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better? You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.

> The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better? Because it puts them in an overengineered, overly cumbersome hierarchy under that. It reminds me of OSI. > You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.confi…

> an overengineered, overly cumbersome hierarchy under that.

You put config files in $XDG_CONFIG_HOME/app/whatever with a fallback to $HOME/.config/app/whatever, and data files in $XDG_DATA_HOME/app/whatever with a fallback to $HOME/.local/share/app/whatever - what exactly is over engineered or cumbersome about that?

Re: Use the XDG Base Directory Specification

#12
> ... State :... if the data is unique for a given machine, the file belongs [to $XDG_STATE_HOME / $HOME/.local/state]

This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user.

Also, why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the rules, these files should be within the .config/ directory as well.

Re: Use the XDG Base Directory Specification

#13

The second example is a nice start, but I'd really like to see invisible files/folders in ~/ done away with altogether. So starting with that example, I might add a visible ~/Library/ folder, then move ~/.config/ and ~/.local/ in there as ~/Library/Config/ and ~/Library/Local/ as normal visible folders. Same for .bashrc, .profile, etc; put them in ~/Library/Config/ without the dots.

Luckily if you’re a developer on MacOS, you can have that too! In addition to ~/.config and a million .dotfiles and .dotdirectories from decades of unixy tools! Truly a cornucopia.

Re: Use the XDG Base Directory Specification

#14

The second example is a nice start, but I'd really like to see invisible files/folders in ~/ done away with altogether. So starting with that example, I might add a visible ~/Library/ folder, then move ~/.config/ and ~/.local/ in there as ~/Library/Config/ and ~/Library/Local/ as normal visible folders. Same for .bashrc, .profile, etc; put them in ~/Library/Config/ without the dots.

Luckily if you’re a developer on MacOS, you can have that too! In addition to ~/.config and a million .dotfiles and .dotdirectories from decades of unixy tools! Truly a cornucopia.

It's frustrating enough to make a person seriously consider maintaining forks of all the FOSS things they use to fix this one bit of misbehavior.

Re: Use the XDG Base Directory Specification

#17
post #6

Earlier quoted context omitted.

> The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better? Because it puts them in an overengineered, overly cumbersome hierarchy under that. It reminds me of OSI. > You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.confi…

FYI, and nothing personal, but your comment is more or less coming across to me as "whelp, the inflexible delegation has spoken". I go to great lengths to maintain a flexible mindset, to try to get the best out of a new approach. Hearing/reading someone trying to throw a shallow take-down of something they haven't tried doesn't read as "ooh that person is so cool I'm super convinced"... it comes across more like "oh,…

> Hearing/reading someone trying to throw a shallow take-down of something they haven't tried

I mean, I've lived with XDG messing up where my config files are for several years at this point. How much "trying it" do I have to do to be allowed to have an opinion?

Re: Use the XDG Base Directory Specification

#18
post #12

> ... State :... if the data is unique for a given machine, the file belongs [to $XDG_STATE_HOME / $HOME/.local/state] This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user. Also, why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the ru…

> Also, why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the rules, these files should be within the .config/ directory as well.

I was wondering about that part as well. Then again, I also have high standards for non-hidden stuff as well, and only have ~/Downloads from the ones they list. I do have a ~/Dropbox/home` with `docs` and `images` (as well as "video", but not synced locally), as well as ~/code and ~/dotfiles. If anything, having non-hidden clutter stresses me far more than hidden clutter; I have ~/.scratch for random on-off things I need, and I'll often utilize my disdain for extra stuff in the home directory as a way to make sure that I don't procrastinate something too long (e.g. if I need to make a phone call for some errand or something, I might put `phone.txt` in my home directory with the number I need to call, and seeing that every time I look at my home directory I get a reminder until I do it and delete the file).

Re: Use the XDG Base Directory Specification

#19
post #12

> ... State :... if the data is unique for a given machine, the file belongs [to $XDG_STATE_HOME / $HOME/.local/state] This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user. Also, why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the ru…

Those files are not in optional locations. You could possibly symlink from ~/.bashrc to ~/.config/bash/bashrc, but what's the point of that?

Re: Use the XDG Base Directory Specification

#20
post #19
post #12

> ... State :... if the data is unique for a given machine, the file belongs [to $XDG_STATE_HOME / $HOME/.local/state] This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user. Also, why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the ru…

Those files are not in optional locations. You could possibly symlink from ~/.bashrc to ~/.config/bash/bashrc, but what's the point of that?

Not completely true. You can launch bash with the --init-file flag and put the bashrc file wherever you'd like. Could even change /bin/bash or whatever your default shell is to be a script that launches bash with that flag provided.
Post reply on HN