[Eduard]

> ... 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.

[pxc]

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

No, it's both. The XDG state dir is for things that are also machine-specific so that, e.g., it doesn't make sense to sync them as part of your dotfiles.

> 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.

They should! Some shells have kindly moved to follow this convention following requests from users who like it for other apps and would prefer more uniformity w/r/t config file location conventions, e.g.: https://github.com/elves/elvish/issues/383

[yjftsjthsd-h]

> No, it's both. The XDG state dir is for things that are also machine-specific so that, e.g., it doesn't make sense to sync them as part of your dotfiles.

It was probably written back when it was more common to have your home on NFS, although I'm not sure how that would work without needing to use overlayfs per-machine or something.

[vetinari]

Or maybe you want to sync your config across multiple machines. Like desktop and laptop.

[imbnwa]

Also Fish shell

[kelnos]

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

No, it's correct. "State" data is machine-specific. You might run an application that needs to generate a machine-specific identifier on first run and save it somewhere. For someone who shares their ~/.config among multiple machines, that shouldn't be synced.

> when it has files .profile and .bashrc placed directly in the user's home directory?

There's no other good option, as you may have a chicken-and-egg problem: often people put their definition of XDG_CONFIG_HOME in their .profile or .bashrc. Bash can't know where to find the file if the file tells you where to find it.

Sure, it could just hard-code ~/.config (and that would be correct for most people), but for people who have it set to something else, now they just have an unwanted ~/.config directory. Might as well just stick it in ~/ and live with it.

Of course there are alternatives: someone could set those variables via a PAM module or some other mechanism that might be able to set it before the shell even starts, but I'm not sure we should expect that to be common either. You could also use /etc/profile or /etc/bashrc, but then you have to either set it for all users, or have an if/case statement or user-mapping file that sets things according to each user's preference. If this is a shared machine where most users don't have root access, then you need a mechanism that lets users update their preference.

Yes, I get that those things are not the common case: most people have a single-user desktop/laptop where they have root access. But we need to consider the edge cases too.

[saghm]

> 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).

[clhodapp]

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!

[kelnos]

That's the thing I always thought was weird: why isn't the default value for XDG_CONFIG_HOME ~/.local/etc, and XDG_CACHE_HOME ~/.local/var/cache? I guess they wanted to make it easier to find for people who wouldn't be familiar with the spec (i.e., most regular users).

[speed_spread]

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.

[chungy]

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

[toolz]

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.

[pbhjpbhj]

Is there a simple way to maintain that through updates?

[toolz]

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