Live data from Hacker News

Use the XDG Base Directory Specification

xdgbasedirectoryspecification.com

91–100 of 214 posts

Re: Use the XDG Base Directory Specification

#91

Earlier quoted context omitted.

> I want it clearly visible such as ~/config. No problems: define the $XDG_CONFIG_HOME to be like so. > I don't want an additional and confusing ~/.local. The idea is that data and config are different. Anyway, if you have different taste, that's ok, define $XDG_DATA_HOME to be the same as config. > I don't want ~/Videos or ~/Pictures folders That's not in the XDG spec.

> That's not in the XDG spec. But it is. In the XDG user dir spec.

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.

Re: Use the XDG Base Directory Specification

#93
post #21

Earlier quoted context omitted.

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

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

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

Re: Use the XDG Base Directory Specification

#94
post #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.

Any GUI file manager worth its salt can hide invisible and/or dotfiles, it’s table stakes — and just a GUI representation of that same terminal output.

Re: Use the XDG Base Directory Specification

#95
post #17

Earlier quoted context omitted.

> Hearing/reading someone trying to throw a shallow take-down of something they haven't tried I mean, I've lived with XDG messing up where my config files are for several years at this point. How much "trying it" do I have to do to be allowed to have an opinion?

> I mean, I've lived with XDG messing up where my config files are for several years Why don't you set your XDG vars to where you want to put them then? What's your alternative? Force everyone to follow your preference instead of having it configurable?

> Why don't you set your XDG vars to where you want to put them then?

I hear that argument often. When a program uses $XDG_CONFIG_HOME/tool/ for its config files, to what value should I set XDG_CONFIG_HOME to get the old behavior where it puts its config in $HOME/.tool/?

Re: Use the XDG Base Directory Specification

#96

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 X…

.gitignore in $HOME/.config:

```

*

!nvim/

!dunst/

!i3/

```

Then you have a whitelist which is clearly not that hard to maintain

For the cache, the opposite argument is just as true:

If I want to clear cache from everything to save space, I can just `rm -rf ~/.cache` instead. And this case is a lot more common than wanting to "start from a clean profile" :/

Re: Use the XDG Base Directory Specification

#97

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 X…

> Easier to create backups

i want to mess up with wine, now I just backup ~/.wine, do whatever, restore.

With split folders, i'd have to backup a bunch of folders (.config/wine, .local/share/wine, .local/lib/wine or wherever the files, registry, dosdevices and other stuff would be put).

Re: Use the XDG Base Directory Specification

#98
post #83

Earlier quoted context omitted.

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.

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

Re: Use the XDG Base Directory Specification

#99
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…

> There are seemingly two packages for this, neither of which I could get to work.

I am really confused as to how that happened so I will show examples of all the three options I know of and how to use them to get a path of a config to load:

https://pypi.org/project/appdirs/ - simple, even works on windows

    from appdirs import user_config_dir
    import os
    # Company is optional for windows support to work the way windows users expect it.
    # You can also specify version to version the dirs.
    conf_dir = user_config_dir("program", "company")
    conf_path = os.path.join(conf_dir, "config.toml")
https://pypi.org/project/xdg-base-dirs/ - just bare bones XDG support with fall backs and pathlib support, no special windows support, but will still work for user configs

    from xdg_base_dirs import xdg_config_home
    conf_path = xdg_config_home() / "program" / "config.toml"
https://pypi.org/project/pyxdg/ - from freedesktop, includes more than just the base directory specification - a bit of a weird interface but technically can support more complex situations

    from xdg.BaseDirectory import load_first_config
    import os
    conf_dir = load_first_config("program")
    # conf_dir will be none if there is no "program" dir/file in any of the paths XDG_CONFIG_HOME or XDG_CONFIG_DIRS
    if conf_dir:
        conf_path = os.path.join(conf_dir, "config.toml")
Yes there are 3 options (but what modern language doesn't have this problem for everything?) and you have to pick one. It's not that hard to evaluate these, the only caveats you have to consider are: do I care about system-wide configurations and properly handling overlapping configurations, or do I just want a user local config directory. I have written the above code with consideration for the latter. If you are allergic to unnecessary dependencies (and I am so I can sympathize) then for the simple use case I outlined (with the same level of cross-platform support as xdg-base-dirs and pyxdg) you can just use this code:

    from pathlib import Path
    import os

    conf_home = os.environ.get('XDG_CONFIG_HOME')
    conf_home = Path(conf_home) if conf_home else Path.home() / ".config"
    conf_path = conf_home / "program" / "config.toml"
I hereby release all code (within this comment) under CC0 (I doubt you could even claim copyright on something so simple anyway, but let's avoid issues in advance).

> but apps often dump the default configuration into the config dir

This is not an XDG dir related problem, and not even that common of a problem. You are right that it IS a problem (and applications should be encouraged to avoid this, just as they should be encouraged to avoid littering the homedir) but strictly speaking, using .config while littering it with auto-generated configs is better than not using config while doing the same. It really does make life easier when configuration is generally kept separate from other types of data by following the XDG base directory specification.

Re: Use the XDG Base Directory Specification

#100
post #96

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 X…

.gitignore in $HOME/.config: ``` * !nvim/ !dunst/ !i3/ ``` Then you have a whitelist which is clearly not that hard to maintain For the cache, the opposite argument is just as true: If I want to clear cache from everything to save space, I can just `rm -rf ~/.cache` instead. And this case is a lot more common than wanting to "start from a clean profile" :/

> I can just `rm -rf ~/.cache

But can you? Did you really close all the apps using ~/.cache? What if some app is just doing some cleanup operation, moves a bunch of stuff to cache, and the files are missing now? Did you just delete android studio cache in the middle of a compile?

You can also make a script like your .config, but it's called "clear_cache.sh", where you hardcore a few paths you usually clean manually.

Post reply on HN