8 ms·

I am increasingly exasperated by apps that do not follow the XDG specification for config at this point. Having a ton of dotfiles sitting in the root of the hom

I am increasingly exasperated by apps that do not follow the XDG specification for config at this point. Having a ton of dotfiles sitting in the root of the home directory is just a maintenance nightmare on every level. I've gone so far as to keep my config directory visible -- ~/.config is a symlink to ~/config, which actually holds all my config, conveniently a git repository in itself for easy portability and tracking.

lillecarl 4y ago
What a genius idea, I'm gonna write a shell function to "permanently unhide" everything in a directory, I love *nix
- anamexis 4y ago
  That "function" for me is just `alias ls='ls -a'`
  - lillecarl 4y ago
    Not the same, though there are more tools than ls that use directories.
qbasic_forever 4y ago
Stow is a tool designed to support exactly the workflow you describe: https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/
- spinningarrow 4y ago
  Been using stow for my dotfiles for many years now and I’m really happy with the workflow: https://github.com/spinningarrow/.files https://github.com/spinningarrow/.files
luma 4y ago
It really is a mess and it would be helpful if we had some sort of database for configuration that was reasonably standardized. Some sort of "registry" if you will :D
- overlisted 4y ago
  GNOME has dconf[1], but it's only usable through D-Bus, which probably annoys the anti-systemd people [1] https://en.wikipedia.org/wiki/Dconf https://en.wikipedia.org/wiki/Dconf
  - MichaelCollins 4y ago
    It probably annoys most people who are accustomed to using their preferred text editor to configure their software, and it probably also annoys all the other users who are accustomed to using typical GUI preference windows accessed through the menus to change their configuration. Things like dconf and about:config exists in no man's land, where neither generic GUI skills nor generic unixy skills are applicable.
    - forgotpwd16 4y ago
      >and it probably also annoys all the other users who are accustomed to using typical GUI preference windows accessed through the menus to change their configuration How is this a problem with dconf? GNOME Settings for example is typical GUI preferences and works as a front-end to the dconf database.
      - enduser 4y ago
        It's not exactly a feature to have several layers of abstraction, when a text editor could suffice.
        overlisted 4y ago
        Unix will never to achieve true user-friendliness and wide adoption if we treat settings like this. The reality is that most people need a graphical, hard to break way of changing their settings to use your software. Edit: Although I agree that some situations may require a readable text format, like a dotfiles repo. I personally use the `dconf-editor` program to find the right keys and the `dconf load` command to sync them from a regedit-like file format
kazinator 4y ago
"Having a ton of sheep rounded up in one enclosure is a herding nightmare; why can't they be scattered among the numerous meadows, ravines and gulleys that grace these mountains?"
- Gordonjcp 4y ago
  The latter is exactly how you keep sheep. Keeping them in one enclosure is more of a pain in the arse to cope with than having to spend half a day tromping around with a couple of dogs herding them back into an enclosure, and then sorting out which sheep belongs to who. I'm not quite sure why this is a good analogy, but it feels like it is.
colordrops 4y ago
You should consider Nix home-manager. It keeps config all in one place and explicit.
- DoneWithAllThat 4y ago
  > Unfortunately, it is quite possible to get difficult to understand errors when working with Home Manager, such as infinite loops with no clear source reference. You should therefore be comfortable using the Nix language and the various tools in the Nix ecosystem. Reading through the Nix Pills document is a good way to familiarize yourself with them. Thanks, but I’ll just deal with a bunch of dotfiles. This sounds an awful lot like a “and now you have two problems” situation.
  - colordrops 4y ago
    Whatever works for you, but it's not really a fair characterization. It adds one problem and solves another dozen, at least in my case. And I don't really run into these difficult to diagnose issues too often. It's like driving a car instead of walking is trading one problem for two. I'm to blame actually, it does a lot more than config management, so I mischaracterized it myself.
  - willmorrison 4y ago
    Home Manager really doesn’t lead to many problems, and if you encounter any the NixOS community is wonderful. You can set up everything without understanding much of the Nix language by looking at other people’s configs on GitHub.
  - ben0x539 4y ago
    The new problem is pretty fun though!
user3939382 4y ago
If I ever find time to play with hacking the kernel my first project is to create an extension that automatically redirects all file system lookups for ~/.* to ~/.config/* I’ll even forgo having my own hidden files there, I don’t care. It’s so annoying.
- SAI_Peregrinus 4y ago
  So you WANT ~/.cache/ in ~/.config/? It's enough of a nightmare when Electron-based apps litter their folders in ~/.config with service worker caches, that'd make it even worse. It's annoying to need a gigantic .gitignore for all the cache files in ~/.config IMO.
- the_gipsy 4y ago
  Don't forget to add the `.config` exception!
- layer8 4y ago
  How about glob symlinks as a filesystem feature? :) ln -sg '~/config/*' '~/.*'
- deleted 4y ago
  [deleted]
Kaze404 4y ago
I stopped caring about this by having home-manager do all this for me. I don't really care where the files are anymore because I change them through Nix, not directly, and I can choose where that is located.
- amarshall 4y ago
  Further, using a tmpfs for root (and by extension ~), means that junk doesn’t accumulate (while Home Manager ensures what should be there, is there).
m-n 4y ago
> I've gone so far as to keep my config directory visible -- ~/.config is a symlink to ~/config, which actually holds all my config, conveniently a git repository in itself for easy portability and tracking. Sometimes I wonder how much defaulting to a directory with a leading dot hurt adoption. It gave me the impression that it was designed for or by people who don't manually edit their config files.
- bayindirh 4y ago
  It's not defaulting to a directory, but to a variable: "$XDG_CONFIG_HOME". Also, if you know how to change config of an application for the last 15-16 years, you also know that you're going to edit a "dot file". KDE stored everything under ".kde" for a long long time, and stored a great tree under it too. rc files as config files and other KDE related files as app specific files. In fact, the ".config" folder is just an evolution of ".kde" folder. Spec is written by KDE guys.
  - m-n 4y ago
    > It's not defaulting to a directory, but to a variable: "$XDG_CONFIG_HOME". By default I'm referring to the following part of the spec and the fact that systems I've used start in this state: > If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.
bayindirh 4y ago
The XDG specification is fairly young. It's a bit younger than a decade. So, I don't expect older packages to update to it. Also, some applications use their older files if they find it, and re-create under XDG spec when they fail to find that file. KDE did that to great extent and success, for example.
swyx 4y ago
info on XDG: [the XDG spec](https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html https://standards.freedesktop.org/basedir-spec/basedir-spec-...) tools that respect XDG, for fellow JS CLI developers: - https://github.com/davidtheclark/cosmiconfig https://github.com/davidtheclark/cosmiconfig Find and load configuration from a package.json property, rc file, or CommonJS module. [Check `searchPaths` to implement XDG spec compliance.](https://github.com/davidtheclark/cosmiconfig/issues/152 https://github.com/davidtheclark/cosmiconfig/issues/152) - Sindre's libraries use [`env-paths`](https://github.com/sindresorhus/env-paths#pathsconfig https://github.com/sindresorhus/env-paths#pathsconfig) to get paths compliant with this. - https://github.com/sindresorhus/conf https://github.com/sindresorhus/conf simple config storing (maybe try [conf-cli](https://github.com/natzcam/conf-cli https://github.com/natzcam/conf-cli) to manipulate if needed) the successor to [configstore](https://github.com/sindresorhus/conf#how-is-this-different-from-configstore https://github.com/sindresorhus/conf#how-is-this-different-f...) - https://github.com/jonschlinkert/data-store https://github.com/jonschlinkert/data-store conf like datastore but in the shclinkerverse
_8j50 4y ago
Neat idea with the git part.
qudat 4y ago
I do something similar, managing dotfiles is pretty easy with a git repo
jart 4y ago
I'm exasperated by apps that hide their configuration files deep within my home directory and I have to use strace to figure out where they are. XDG is mostly useful for people who use unix desktops. It's sort of like a compromise between dotfiles and regedit.exe. Because desktops are huge and complex. If you ask your package manager to install one desktop thing, it installs a hundred things. Non desktop UNIX environments don't have that problem. So I don't think CLI programs like htop shouldn't follow XDG. It's non-standard and not the right tool.
- yjftsjthsd-h 4y ago
  > I'm exasperated by apps that hide their configuration files deep within my home directory and I have to use strace to figure out where they are. That does sound annoying; if only every application would just use ~/.config/appname then your problem would be solved.
- chimprich 4y ago
  > So I don't think CLI programs like htop shouldn't follow XDG. I'm confused by your double negative. It looks like you're saying CLI tools should follow XDG, but the tone of your post sounds like the opposite. If the latter, what are you, some of kind of monster? :) If you don't want a specific XDG config dir, set it to ~. Don't force us all to follow some antiquated convention from days of yore.
layer8 4y ago
I always (since long before XDG became a thing) used ~/etc, in analogy to /etc. Also ~/bin, ~/var, and ~/tmp.
deleted 4y ago
[deleted]
bjourne 4y ago
I've been filing a few bug reports on software that puts its config in dotfiles in ~/. Hopefully we can reach critical mass sooner or later. Because the more projects that follow XDG the more pressure on the projects that have not migrated yet. It makes the Linux desktop better for everyone.
pabs3 4y ago
You can do away with that symlink by setting the XDG environment variables.

lillecarl 4y ago

What a genius idea, I'm gonna write a shell function to "permanently unhide" everything in a directory, I love *nix

anamexis 4y ago
That "function" for me is just `alias ls='ls -a'`
- lillecarl 4y ago
  Not the same, though there are more tools than ls that use directories.

qbasic_forever 4y ago

Stow is a tool designed to support exactly the workflow you describe: https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/

spinningarrow 4y ago
Been using stow for my dotfiles for many years now and I’m really happy with the workflow: https://github.com/spinningarrow/.files https://github.com/spinningarrow/.files

luma 4y ago

It really is a mess and it would be helpful if we had some sort of database for configuration that was reasonably standardized. Some sort of "registry" if you will :D

overlisted 4y ago
GNOME has dconf[1], but it's only usable through D-Bus, which probably annoys the anti-systemd people [1] https://en.wikipedia.org/wiki/Dconf https://en.wikipedia.org/wiki/Dconf
- MichaelCollins 4y ago
  It probably annoys most people who are accustomed to using their preferred text editor to configure their software, and it probably also annoys all the other users who are accustomed to using typical GUI preference windows accessed through the menus to change their configuration. Things like dconf and about:config exists in no man's land, where neither generic GUI skills nor generic unixy skills are applicable.
  - forgotpwd16 4y ago
    >and it probably also annoys all the other users who are accustomed to using typical GUI preference windows accessed through the menus to change their configuration How is this a problem with dconf? GNOME Settings for example is typical GUI preferences and works as a front-end to the dconf database.
    - enduser 4y ago
      It's not exactly a feature to have several layers of abstraction, when a text editor could suffice.
      - overlisted 4y ago
        Unix will never to achieve true user-friendliness and wide adoption if we treat settings like this. The reality is that most people need a graphical, hard to break way of changing their settings to use your software. Edit: Although I agree that some situations may require a readable text format, like a dotfiles repo. I personally use the `dconf-editor` program to find the right keys and the `dconf load` command to sync them from a regedit-like file format

kazinator 4y ago

"Having a ton of sheep rounded up in one enclosure is a herding nightmare; why can't they be scattered among the numerous meadows, ravines and gulleys that grace these mountains?"

Gordonjcp 4y ago
The latter is exactly how you keep sheep. Keeping them in one enclosure is more of a pain in the arse to cope with than having to spend half a day tromping around with a couple of dogs herding them back into an enclosure, and then sorting out which sheep belongs to who. I'm not quite sure why this is a good analogy, but it feels like it is.

colordrops 4y ago

You should consider Nix home-manager. It keeps config all in one place and explicit.

DoneWithAllThat 4y ago
> Unfortunately, it is quite possible to get difficult to understand errors when working with Home Manager, such as infinite loops with no clear source reference. You should therefore be comfortable using the Nix language and the various tools in the Nix ecosystem. Reading through the Nix Pills document is a good way to familiarize yourself with them. Thanks, but I’ll just deal with a bunch of dotfiles. This sounds an awful lot like a “and now you have two problems” situation.
- colordrops 4y ago
  Whatever works for you, but it's not really a fair characterization. It adds one problem and solves another dozen, at least in my case. And I don't really run into these difficult to diagnose issues too often. It's like driving a car instead of walking is trading one problem for two. I'm to blame actually, it does a lot more than config management, so I mischaracterized it myself.
- willmorrison 4y ago
  Home Manager really doesn’t lead to many problems, and if you encounter any the NixOS community is wonderful. You can set up everything without understanding much of the Nix language by looking at other people’s configs on GitHub.
- ben0x539 4y ago
  The new problem is pretty fun though!

user3939382 4y ago

If I ever find time to play with hacking the kernel my first project is to create an extension that automatically redirects all file system lookups for ~/.* to ~/.config/* I’ll even forgo having my own hidden files there, I don’t care. It’s so annoying.

SAI_Peregrinus 4y ago
So you WANT ~/.cache/ in ~/.config/? It's enough of a nightmare when Electron-based apps litter their folders in ~/.config with service worker caches, that'd make it even worse. It's annoying to need a gigantic .gitignore for all the cache files in ~/.config IMO.
the_gipsy 4y ago
Don't forget to add the `.config` exception!
layer8 4y ago
How about glob symlinks as a filesystem feature? :) ln -sg '~/config/*' '~/.*'
deleted 4y ago
[deleted]

Kaze404 4y ago

I stopped caring about this by having home-manager do all this for me. I don't really care where the files are anymore because I change them through Nix, not directly, and I can choose where that is located.

amarshall 4y ago
Further, using a tmpfs for root (and by extension ~), means that junk doesn’t accumulate (while Home Manager ensures what should be there, is there).

m-n 4y ago

> I've gone so far as to keep my config directory visible -- ~/.config is a symlink to ~/config, which actually holds all my config, conveniently a git repository in itself for easy portability and tracking. Sometimes I wonder how much defaulting to a directory with a leading dot hurt adoption. It gave me the impression that it was designed for or by people who don't manually edit their config files.

bayindirh 4y ago
It's not defaulting to a directory, but to a variable: "$XDG_CONFIG_HOME". Also, if you know how to change config of an application for the last 15-16 years, you also know that you're going to edit a "dot file". KDE stored everything under ".kde" for a long long time, and stored a great tree under it too. rc files as config files and other KDE related files as app specific files. In fact, the ".config" folder is just an evolution of ".kde" folder. Spec is written by KDE guys.
- m-n 4y ago
  > It's not defaulting to a directory, but to a variable: "$XDG_CONFIG_HOME". By default I'm referring to the following part of the spec and the fact that systems I've used start in this state: > If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

bayindirh 4y ago

The XDG specification is fairly young. It's a bit younger than a decade. So, I don't expect older packages to update to it. Also, some applications use their older files if they find it, and re-create under XDG spec when they fail to find that file. KDE did that to great extent and success, for example.

swyx 4y ago

info on XDG: [the XDG spec](https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html https://standards.freedesktop.org/basedir-spec/basedir-spec-...) tools that respect XDG, for fellow JS CLI developers: - https://github.com/davidtheclark/cosmiconfig https://github.com/davidtheclark/cosmiconfig Find and load configuration from a package.json property, rc file, or CommonJS module. [Check `searchPaths` to implement XDG spec compliance.](https://github.com/davidtheclark/cosmiconfig/issues/152 https://github.com/davidtheclark/cosmiconfig/issues/152) - Sindre's libraries use [`env-paths`](https://github.com/sindresorhus/env-paths#pathsconfig https://github.com/sindresorhus/env-paths#pathsconfig) to get paths compliant with this. - https://github.com/sindresorhus/conf https://github.com/sindresorhus/conf simple config storing (maybe try [conf-cli](https://github.com/natzcam/conf-cli https://github.com/natzcam/conf-cli) to manipulate if needed) the successor to [configstore](https://github.com/sindresorhus/conf#how-is-this-different-from-configstore https://github.com/sindresorhus/conf#how-is-this-different-f...) - https://github.com/jonschlinkert/data-store https://github.com/jonschlinkert/data-store conf like datastore but in the shclinkerverse

_8j50 4y ago

Neat idea with the git part.

qudat 4y ago

I do something similar, managing dotfiles is pretty easy with a git repo

jart 4y ago

I'm exasperated by apps that hide their configuration files deep within my home directory and I have to use strace to figure out where they are. XDG is mostly useful for people who use unix desktops. It's sort of like a compromise between dotfiles and regedit.exe. Because desktops are huge and complex. If you ask your package manager to install one desktop thing, it installs a hundred things. Non desktop UNIX environments don't have that problem. So I don't think CLI programs like htop shouldn't follow XDG. It's non-standard and not the right tool.

yjftsjthsd-h 4y ago
> I'm exasperated by apps that hide their configuration files deep within my home directory and I have to use strace to figure out where they are. That does sound annoying; if only every application would just use ~/.config/appname then your problem would be solved.
chimprich 4y ago
> So I don't think CLI programs like htop shouldn't follow XDG. I'm confused by your double negative. It looks like you're saying CLI tools should follow XDG, but the tone of your post sounds like the opposite. If the latter, what are you, some of kind of monster? :) If you don't want a specific XDG config dir, set it to ~. Don't force us all to follow some antiquated convention from days of yore.

layer8 4y ago

I always (since long before XDG became a thing) used ~/etc, in analogy to /etc. Also ~/bin, ~/var, and ~/tmp.

deleted 4y ago

[deleted]

bjourne 4y ago

I've been filing a few bug reports on software that puts its config in dotfiles in ~/. Hopefully we can reach critical mass sooner or later. Because the more projects that follow XDG the more pressure on the projects that have not migrated yet. It makes the Linux desktop better for everyone.

pabs3 4y ago

You can do away with that symlink by setting the XDG environment variables.