Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use the XDG Base Directory Specification

xdgbasedirectoryspecification.com

Post reply on HN
Print view View original

141–150 of 214 posts

Re: Use the XDG Base Directory Specification

#141

Post by speed_spread »

clhodapp wrote: post #31
Eduard wrote: 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…

It doesn't feel tidy to have .cache or .config out at the root of home folder either. IMO, those should be pushed down into .local. At least with the xdg base spec you can do that!

Even with .config and .cache, the number of .folders in homedir stays constant vs the number of apps installed, which is the most important thing IMO. From there it could be argued that if you allow .local to exist at all and it only contains always the same three subfolders, you might as well move those up and benefit from shorter, more meaningful paths.

Re: Use the XDG Base Directory Specification

#142

Post by account42 »

okasaki wrote: post #72

A couple of years ago I wanted to use xdg dirs in a Python app I was writing. There are seemingly two packages for this, neither of which I could get to work. Overall I don't think xdg dirs on Linux are really as amazing as some people think. For example it is said that one can just back up the config dir to carry all the configuration over to the next install, but apps often dump the default configuration into the c…

> For example it is said that one can just back up the config dir to carry all the configuration over to the next install, but apps often dump the default configuration into the config dir, which you don't want to carry to the next install (which will have different versions, so probably a different default config) because that might break stuff. In the end you have to carefully look over all the configuration to see what's worthwhile to take with you, and it doesn't really matter if that's in ~/.appname or ~/.config/appname

Depends really what you want. If you want to have a fresh system with some of your config then sure, you need to decide what you want. If you just want to keep the same setup then ... I have been using the same $HOME for over 15 years (same for the rest of the system too). Some big upgrades (e.g. KDE3->4) required some manual intervention but most programs handle old config well enough in my experience.

Re: Use the XDG Base Directory Specification

#143

Post by spott »

kitsunesoba wrote: post #14
drunkpotato wrote: post #13

Earlier quoted context omitted.

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.

Start with pythons “projectdirs”, which refuses to allow mac systems to use XDG or at least have that option.

https://github.com/platformdirs/platformdirs/issues/4

Re: Use the XDG Base Directory Specification

#144

Post by account42 »

comex wrote: post #51
OJFord wrote: 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 kinds of programs that were putting in entirely nonstandard paths (~/app.config), or paths specific to macOS or Windows, are still doing that. But when it comes to a 'well-behaved' Unix program, there used to be one place to look for its configuration, and now there are three. That is, a program foo could still have its configuration in ~/.foo, but now it can also have it in ~/.config/foo or ~/.local/share/foo. I…

With the XDG Basedir Spec you don't have to use ~/.local/share and ~/.config if you don't like them, they are just the defaults after all and you can set the respective environment variables to whatever you want. That is not an option you had before.

Admittedly, it would have been nice if the variables were defined in a way that let you reproduce the traditional dotfiles, e.g. by pasting $XDG_DATA_HOME in front of the app name so you could set XDG_DATA_HOME=$HOME/. and requiring an explicit trailing slash if you want them to be a directory.

Re: Use the XDG Base Directory Specification

#145

Post by arghwhat »

pasc1878 wrote: post #110
xdennis wrote: post #98

Earlier quoted context omitted.

Being like that for a long time is not a justification for terrible defaults.

That is a better default than a hidden directory. It is obvious and so you can set GOPATH Also works better on Windows where .path is not hidden Also it seems Rob Pike one of the creators of Go and involved with early UNIX thinks that . making hidden files was a mistake. Quote via XahLee http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_... - original was Google+ so not existing now.

Sure, hidden folders are a mistake, but less of a mistake than not adhering to standardized folder structures and just littering in people's home folders.

Re: Use the XDG Base Directory Specification

#146

Post by account42 »

goombacloud wrote: post #52

There is a changed version that includes drop-in config files, masking, and loading defaults from /usr/ instead of requiring full config files to live under /etc: https://uapi-group.org/specifications/specs/base_directory_s...

This is much less general since what it means to merge configuration files is extremely domain specific.

Re: Use the XDG Base Directory Specification

#147

Post by account42 »

sam_lowry_ wrote: post #119
jbaber wrote: post #91

Earlier quoted context omitted.

Wait, I get to blame XDG for this? I've never cared about dotfiles since they're invisible. But Videos, Pictures, etc. have always been a nuisance.

I already posted this above, but here is a repost, because I know exactly how you feel: cat ~/.config/user-dirs.dirs XDG_DESKTOP_DIR="$HOME/.Desktop" XDG_DOWNLOAD_DIR="$HOME/tmp" XDG_TEMPLATES_DIR="$HOME/tmp" XDG_PUBLICSHARE_DIR="$HOME/tmp" XDG_DOCUMENTS_DIR="$HOME/tmp" XDG_MUSIC_DIR="$HOME/tmp" XDG_PICTURES_DIR="$HOME/tmp" XDG_VIDEOS_DIR="$HOME/tmp" Note that XDG_DESKTOP_DIR and XDG_DOWNLOAD_DIR have to point to dif…

> Note that XDG_DESKTOP_DIR and XDG_DOWNLOAD_DIR have to point to different directories. In hindsight, this is obvious, but this is also a really stupid "security" bug-o-feature that costed countless hours to countless people.

It's not obvious at all. The only security issue is programs dumping "downloads" on your harddrive without asking you first. Sucks that this is yet another thing that Mozilla has copied from Chrome without thinking.

Re: Use the XDG Base Directory Specification

#149

Post by AnIdiotOnTheNet »

drunkpotato wrote: post #13
kitsunesoba wrote: post #7

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.

In Windows we get dotfiles from any tool badly ported from unixland, plus the myriad ways specified by various Windows standards over the past several decades, plus the innumerable ways that different entities have chosen to interpret those standards, plus whatever bullshit non-standard locations some asshole thought up and decided to ship.

Where is the config for program X?

It could be in the same directory as X, HKLM\Software\X, HKCU\Software\X, The HKLM\Software\XWOW6432Node\X, AppData\Local\X, AppData\Remote\X, AppData\LocalLow\X, ProgramData\X, USERPROFILE\.X, USERPROFILE\Documents\X, USERPROFILE\Saved Games\X, USERPROFILE\Documents\My Saved Games\X, USERPROFILE\.config\X...

Re: Use the XDG Base Directory Specification

#150

Post by teddyh »

kps wrote: post #138
teddyh wrote: post #111

Earlier quoted context omitted.

Beware that any directory other than one under /home might not enjoy the same protections by default by other programs, like systemd’s ProtectHome setting. You’ll also probably want to adjust some settings, like AppArmor’s @{HOMEDIRS} setting.

Does systemd really hardcode "/home" rather than use the user's actual home directory?

Systemd needs the common parent directory of the home directory of all users on the system, in order to protect all user home directories from services. There is no “the” user.
Post reply on HN