Live data from Hacker News

Use the XDG Base Directory Specification

xdgbasedirectoryspecification.com

81–90 of 214 posts

Re: Use the XDG Base Directory Specification

#82

Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178

You can also use the environment file linked in that blog post to tell Rust to follow the XDG standard. Not perfect because it is not the default behaviour but it is doable.

Re: Use the XDG Base Directory Specification

#83

Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178

Somebody should tell this to go people. They just create me a non-hidden directory `~/go`

Re: Use the XDG Base Directory Specification

#84

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.

If everything honored this spec, including the part where it reads environment variables to see where the different directories are, you could do that by sticking the right variables in your environment. I think the one legitimate exception to the rule is profile, because you need that in order to set the variables in the first place. So that one would somehow have to be hard coded to at least have a wider search pat…

Honestly, when your xdg list gets huge, apps should just use xdg out of the box... my /etc/profile is 35 lines of just xdg junk.

Re: Use the XDG Base Directory Specification

#85
post #20
post #19

Earlier quoted context omitted.

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.

Is there a simple way to maintain that through updates?

Re: Use the XDG Base Directory Specification

#86

Earlier quoted context omitted.

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.

Do any of the Linux distros do this? Strikes me as the kind of thing Debian would do for everything in apt

Do you have any examples of Debian doing this?

Re: Use the XDG Base Directory Specification

#87
Does it really help that much in practice?

> Easier to share configuration settings

I want to share my nvim config between both my home Linux machine and my Mac at work, but I don’t want to share my config for gnome and its apps. So now I’ve got to maintain a script to go one more subdirectory deep to pick which dotfiles to sync and which to ignore...

> Easier to temporarily ignore the config > It is easiest to set XDG_CONFIG_HOME=/tmp/dir

This is such an unreliable way to do it, even within the xdg world. What about stuff in ~/.local/share? It’s a lot easier and more reliable to just set HOME=$(mktemp -d)

Personally when I’m trying to start from a clean profile, I find it much easier to just go and blow away ~/.mozilla than to go and surgically remove .config/epiphany, .local/share/epiphany, .cache/epiphany, and whatever gconf (or gsettings or whatever windows registry clone we’ve got now) settings it’s got.

Re: Use the XDG Base Directory Specification

#88
My one gripe is that many systems do not provide a writable XDG_RUNTIME_DIR in all cases because the requirements in the specification are impossible to meet at the same time (the specification does not acknowledge the existence of “su --login”). This means that applications still need fallback code, which historically has been buggy (e.g., using shared /tmp without safeguards).

Re: Use the XDG Base Directory Specification

#89
post #83

Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178

Somebody should tell this to go people. They just create me a non-hidden directory `~/go`

  export GOPATH=~/Projects/go
Has been like this since forever.

Re: Use the XDG Base Directory Specification

#90
I have finally realized why so many people suddenly care about dotfiles in $HOME. I bet they're all using GUI file managers.

So where I never see these things without an `ls -a`, modern linux users are double clicking a folder and have to scroll past hundreds of dotfiles.

Also explains the X in XDG.

Post reply on HN