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

171–180 of 214 posts

Re: Use the XDG Base Directory Specification

#171

Post by stametseater »

bobthebuilders wrote: post #160
stametseater wrote: post #154

Earlier quoted context omitted.

In my experience, the usual reason for a project not using the XDG Base Dir spec is because somebody on the project simply doesn't like it, particularly XDG_CONFIG_HOME defaulting to $HOME/.config. Resistance to the XDG Base Dir spec really does seem to be rooted in personal preference, I've never seen an objection to it on any technical basis. The best arguments against it that I've seen are "many other projects don…

XDG_BIN_HOME is crucial, without it, not supporting the spec seems like the right call. Better to deal with the status quo until updates happen than to get stuck in bikeshed hell.

You're letting perfect be the enemy of good. Other projects, like python, use $HOME/.local/bin as the spec suggests and it works out fine in virtually all cases.

> "User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place."

> "Since $HOME might be shared between systems of different achitectures, installing compiled binaries to $HOME/.local/bin could cause problems when used on systems of differing architectures. This is often not a problem, but the fact that $HOME becomes partially achitecture-specific if compiled binaries are placed in it should be kept in mind."

https://specifications.freedesktop.org/basedir-spec/basedir-...

The omission of XDG_BIN_HOME is regrettable, but not a showstopping problem unless you want it to be a problem. W.r.t. a single $HOME across multiple architectures, "not often" a problem is an overstatement of the problem; the number of people using a single $HOME across multiple architectures is a rounding error (I say that as somebody who once did so) and such people are already accustomed to dealing with the difficulties that arise from it. They're going to hoist themselves with Go and Rust's defaults anyway.

Re: Use the XDG Base Directory Specification

#173

Post by OJFord »

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…

Sounds like your issue's more with change than specifically what the spec says then. I get that, but also.. where would we be? (But then, I use a rolling release distro (btw) and happen to like systemd.)

> Why does that path need to be two directories deep?

It doesn't, set `$XDG_DATA_HOME` to something that isn't.

Re: Use the XDG Base Directory Specification

#175

Post by yjftsjthsd-h »

eviks wrote: post #170
yjftsjthsd-h wrote: post #169

Earlier quoted context omitted.

> otherwise it wouldn't have a section on Windows. And the Mac section is also weak The Windows section stright-up says they don't really know what the situation is over there, and the macOS section says they couldn't find an official recommendation for non-GUI programs. > Your advice re. Windows is also bad, for example, for a lot of x-platform tools I care more about x-platform consistency and would set the env var…

Your first point is just reiterating my criticism > just want to make your personal stuff do what you expect That's obviously not "just" what I want, so care to come up with an actual reason why moving from the OS dumping ground to a user's custom folder is not a good general advice?

Programs should default to following the platform convention. It's totally fine for a user to decide that they want to stick everything in ~/.config even on Windows, but it's inappropriate for programs to use that as a default.

Re: Use the XDG Base Directory Specification

#176

Post by lovelymono »

yjftsjthsd-h wrote: post #168
lovelymono wrote: post #108

Earlier quoted context omitted.

They could have used ls -A -1 -p which should result in the same output. -A is like -a but will not print . and .. directories. -1 prints one file per line. -p appends / to directories. There's a lot more flags in the man page: https://man7.org/linux/man-pages/man1/ls.1.html

That's GNU ls; AFAICT -1 and -p aren't POSIX so might not work on other unix-likes (most prominently Darwin, but also the BSDs)

https://pubs.opengroup.org/onlinepubs/009696899/utilities/ls... lists both -p and -1. And while -p is marked as an XSI extension, both Darwin and all modern BSD distributions implement it.

Re: Use the XDG Base Directory Specification

#177

Post by benatkin »

OJFord wrote: post #173
comex wrote: post #51

Earlier quoted context omitted.

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…

Sounds like your issue's more with change than specifically what the spec says then. I get that, but also.. where would we be? (But then, I use a rolling release distro (btw) and happen to like systemd.) > Why does that path need to be two directories deep? It doesn't, set `$XDG_DATA_HOME` to something that isn't.

Eh, for me it's that it's a grouping I don't like. I would really rather have the config and data bundled together. It's kind of like OOP where the functions and data are bundled together.

Re: Use the XDG Base Directory Specification

#178

Post by toolz »

pbhjpbhj wrote: post #85
toolz wrote: post #20

Earlier quoted context omitted.

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?

was curious and found this https://hiphish.github.io/blog/2020/12/27/making-bash-xdg-co...

Re: Use the XDG Base Directory Specification

#179

Post by eviks »

yjftsjthsd-h wrote: post #175
eviks wrote: post #170

Earlier quoted context omitted.

Your first point is just reiterating my criticism > just want to make your personal stuff do what you expect That's obviously not "just" what I want, so care to come up with an actual reason why moving from the OS dumping ground to a user's custom folder is not a good general advice?

Programs should default to following the platform convention. It's totally fine for a user to decide that they want to stick everything in ~/.config even on Windows, but it's inappropriate for programs to use that as a default.

I've asked you for an explanation re why following worse defaults is better, not a repetition

Re: Use the XDG Base Directory Specification

#180

Post by yjftsjthsd-h »

lovelymono wrote: post #176
yjftsjthsd-h wrote: post #168

Earlier quoted context omitted.

That's GNU ls; AFAICT -1 and -p aren't POSIX so might not work on other unix-likes (most prominently Darwin, but also the BSDs)

https://pubs.opengroup.org/onlinepubs/009696899/utilities/ls... lists both -p and -1. And while -p is marked as an XSI extension, both Darwin and all modern BSD distributions implement it.

Huh, good catch. Not sure why `man 1p ls` didn't give me that:\
Post reply on HN