17 ms·

Use the XDG Base Directory Specification

275 points by hyperupcall 4y ago

shmerl 4y ago
Yes! Some projects are stuck for years trying to implement this. Firefox for example. > .audacity-data Recent Audacity already fixed this.
- encryptluks2 4y ago
  [dead]
fiddlerwoaroof 4y ago
I strongly disagree: the dot files cause very little inconvenience because they’re typically hidden and they’re easier to type and list than the XDG spec stuff
- OJFord 4y ago
  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.
  - lmm 4y ago
    > The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better? Because it puts them in an overengineered, overly cumbersome hierarchy under that. It reminds me of OSI. > 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. Either of the first two is easier to work with than the XDG-compliant way, and the last is no harder.
    - memetomancer 4y ago
      FYI, and nothing personal, but your comment is more or less coming across to me as "whelp, the inflexible delegation has spoken". I go to great lengths to maintain a flexible mindset, to try to get the best out of a new approach. Hearing/reading someone trying to throw a shallow take-down of something they haven't tried doesn't read as "ooh that person is so cool I'm super convinced"... it comes across more like "oh, poor fella went and got his brain rigidized... and at such a young age". But maybe you'll come around. Maybe people will come around and realize the ankle-deep hot takes are worse than useless and we can all get back to the good stuff. On the other hand, I do have my own suspicions. At first glance it does simply sound like another layer of idiosyncrasy to jam into the memory hole, something that will certainly never be universally adopted and just add more hidey-holes to search for config files. But, as I hope I made clear, I'm willing to give it a shot because I don't trust myself to have absolute insight into a thing after a couple minutes reading. There may well be aspects to this that I can't conjure, but will really like after all is said and done.
      - lmm 4y ago
        > 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?
        chimprich 4y ago
        > 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?
        rkta 4y ago
        > 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/?
  - comex 4y ago
    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. If I don't know where the configuration is already, I have to check all of them. I know ~/.local/share is supposed to be for "data files" and ~/.config is supposed to be for "configuration files", but in practice the distinction seems to be rather unclear. Also, ~/.local/share/foo is a lot slower to type than ~/.foo even with tab completion. Why does that path need to be two directories deep? ~/.config/foo is less bad but still slower.
    - account42 4y ago
      With the XDG Basedir Spec you don't have to use ~/.local/share and ~/.config if you don't like them, they are just the defaults after all and you can set the respective environment variables to whatever you want. That is not an option you had before. Admittedly, it would have been nice if the variables were defined in a way that let you reproduce the traditional dotfiles, e.g. by pasting $XDG_DATA_HOME in front of the app name so you could set XDG_DATA_HOME=$HOME/. and requiring an explicit trailing slash if you want them to be a directory.
    - OJFord 4y ago
      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.
      - benatkin 4y ago
        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.
- deadbunny 4y ago
  vi .co[tab]app[tab] is much easier to remember and type when everything is in the right place.
- kristopolous 4y ago
  Isn't it great that it's optional? I love how Linux is like that. We can all be happy
  - fiddlerwoaroof 4y ago
    Except it isn't because I don't pick the configuration scheme for every program I use.
- benatkin 4y ago
  You're in good company! Most of the apps listed used a hidden file or directory in the home directory.
- sigmonsays 4y ago
  i agree too, All i've seen is a mess of conflicting standards. Is the dotfile now in ~/.local, or ~/.config or what?
  - yjftsjthsd-h 4y ago
    It should be in $XDG_DATA_HOME/app/
  - pasc1878 4y ago
    It depends on what the dotfile is for. If configuration then ~/.config. (which could be empty if you just use the default setup) If for data that the app writes then ~/.local
- eviks 4y ago
  The hidden part is another usability mistake, but the main benefit of XDG is respecting user's choice who can set an env var to avoid the mess, hope you wouldn't disagree with an option the improves someone's life without affecting yours in any way?
  - fiddlerwoaroof 4y ago
    The convention of hiding files starting with a dot is not a usability mistake. It’s a usability improvement.
    - eviks 4y ago
      Why would you hide the files a user is explicitly expected to tweak to configure an app's behavior and call it an improvement??? It degrades the config experience, what part of "usability" is improved? Also, fun historical fact: it was a bug when it was implemented https://linux-audit.com/linux-history-how-dot-files-became-hidden-files/ https://linux-audit.com/linux-history-how-dot-files-became-h...
- pantalaimon 4y ago
  It’s much easier to back up/certain config files when they are all in one place.
kitsunesoba 4y ago
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.
- drunkpotato 4y ago
  Luckily if you’re a developer on MacOS, you can have that too! In addition to ~/.config and a million .dotfiles and .dotdirectories from decades of unixy tools! Truly a cornucopia.
  - kitsunesoba 4y ago
    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.
    - petesergeant 4y ago
      Do any of the Linux distros do this? Strikes me as the kind of thing Debian would do for everything in apt
      - gjvc 4y ago
        Do you have any examples of Debian doing this?
        petesergeant 4y ago
        Sure. In software of mine distributed by Debian, there's usually a "debian/patches" directory, that I didn't add, that's changes the Debian project wanted to make to the system. I'm sure there's a formal name for that system. Most Debian packages seem to have one.
    - 4y ago
prussian 4y ago
I'd say for windows, you'd probably want to define them as well since a lot of ports will use HOME, XDG_* and other non-windowsy environment variables anyhow.
- justeleblanc 4y ago
  Those are shitty ports. The worst are those who will plop something in a dot file in your home directory. They don't get hidden on windows, people!
Eduard 4y ago
> ... 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.
- saghm 4y ago
  > 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).
- chungy 4y ago
  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 4y ago
    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.
WiSaGaN 4y ago
If you are using Rust, you can easily conform to this by using `directories` crate: https://docs.rs/directories/latest/directories/struct.BaseDirs.html https://docs.rs/directories/latest/directories/struct.BaseDi...
- CameronNemo 4y ago
  I am not going to look it up for every language, but you can safely assume all major languages have a similar library to make this easy.
- justeleblanc 4y ago
  Rust itself doesn't care and puts cargo and rustup in your home.
- deleted 4y ago
  [deleted]
rektide 4y ago
One of the things that changed my life recently, that I hadn't seen before: NeoVim has a NVIM_APPNAME variable that lets you change the app name. So when I wanted to try AstroVim, I just set NVIM_APPNAME=astrovim, and dropped the files in ~/.config/astrovim instead of blowing up my existing (shitty) ~/.config/nvim. I really wish the idea of configurable appnames was a part of the spec! (or a well-known extension!)
- kzrdude 4y ago
  It's a very recent neovim feature, so it has not been around to discover for that long
  - rektide 4y ago
    Yes, it's only a month old! https://github.com/neovim/neovim/pull/22128 https://github.com/neovim/neovim/pull/22128 I actually have something similar in some of my old old projects. And I'd expect I ripped the idea off from somewhere. But I don't know who to cite. :(
- Oxodao 4y ago
  Thanks for this tips! Didn't knew it either
- kps 4y ago
  Historically a lot of programs would use argv[0] as their name. Vi-family editors do have an excuse not to do that, since vi uses its name for other purposes, e.g. `view` for readonly.
rapiz 4y ago
I have been long expecting a daemon that picks up scattered config files and make soft links to ~/.config
000ooo000 4y ago
In what world is simply dumping config items for your app in the user's home directory sensible? Why stop at config items? Do cache or temp crap too. The thought process of persisting with this baffles me. Microsoft would be absolutely ridiculed if one day your msword preferences appeared on your desktop as an XML file, and no matter what, it kept reappearing.
- heywoodlh 4y ago
  Yeah, although, I'm not a huge fan of Microsoft's default config file locations either. Some examples: - PowerShell Core's default profile is in $HOME\Documents\PowerShell -- or if you have OneDrive enabled, $HOME\OneDrive\Documents\PowerShell. - Windows Terminal is $HOME\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json. I can feel pretty confident assuming that if Microsoft can place their power users' config files for Microsoft's Terminal and Microsoft's primary shell in seemingly unrelated locations and not get huge complaints, I would imagine that most Windows users are probably not people who would ridicule Microsoft for placing an XML file in their home directory. EDIT: I used these examples specifically, because a Terminal Emulator and shell profile are the exact kind of apps you would store configs for in a dotfiles repo.
  - delta_p_delta_x 4y ago
    Microsoft (and subsidiaries, e.g. 343 Industries), is somehow even worse at adhering to its own norms. Now, I have .vscode and .dotnet folders in the top level of %USERPROFILE%. Even Visual Studio creates a stupid %USERPROFILE%\source\repos directory tree, when I never told it to. I am fed up by this, and have completely given up on maintaining the tidiness of my %USERPROFILE% and %USERPROFILE\Documents. Almost all video games have absolutely no respect whatsoever for OS norms, and just spew their config and save data all over the damn place in %USERPROFILE%\<game title>, %USERPROFILE%\My Games\<game title>, %USERPROFILE%\<developer or publisher>\<game title>. The worst thing is that Windows has a place specifically for video game saves: %USERPROFILE%\Saved Games, or programmatically in C/C++: `SHGetKnownFolderPath(FOLDERID_SavedGames, ...)`. To add to the mix, I also have GNU/Linux-first programs like SSH, Gradle, etc that just straight-up create dot-directories and dotfiles in the top level of %USERPROFILE%. Windows is not Unix/Linux; a dot prefix does not mean 'hidden'. Windows has an explicit 'hidden' filesystem metadata tag that programmers need to (and frequently forget to) set: `SetFileAttributesA(filePath, FILE_ATTRIBUTE_HIDDEN)`. Home, not so sweet home.
olalonde 4y ago
In case anyone else was wondering, XDG stands for X Desktop Group, an older name for freedesktop.org[0]. [0] https://en.wikipedia.org/wiki/Freedesktop.org https://en.wikipedia.org/wiki/Freedesktop.org
- kelnos 4y ago
  Oh huh, I was always under the impression that "X" meant "Cross", as in "Cross-Desktop Group", since they were working on standardizing things across different desktop environments. But I guess the "X" was just a reference to X11? I guess today it encompasses a lot more than X11-based stuff, though...
eviks 4y ago
Weird how this promotional article is weak re advice for the most popular OS (and personal experience isn't the only source of insight)
- yjftsjthsd-h 4y ago
  > for the most popular OS Android doesn't really do dot files. Or config files that the user can see at all. (And if you'd like to amend to "the most used desktop OS", this is obviously aimed at unix-likes, but actually Windows does have an equivalent standard and programs targeting that platform really should be following it just like programs targeting unix-likes really should follow this)
  - eviks 4y ago
    Just like it's obvious what OS I meant, it's also obvious that the article's aim is not as narrow as you're trying to paint it, otherwise it wouldn't have a section on Windows. And the Mac section is also weak, so even that is not a good excuse; and Mac also has a standard, and it's best to ignore it if a user sets an XDG env var 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 to the same ~/.config, e.g., it's much easier to do backup, and I don't care that there is some OS standard (which aren't great to be followed blindly) But even for non x-platform apps that Windows AppData defaults are a dumping ground for app data (not configs) I don't care about and don't need to backup or anything , so if there is an option to put some configs that are more important in a different folder, that's better
    - yjftsjthsd-h 4y ago
      > 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 to the same ~/.config, e.g., it's much easier to do backup, and I don't care that there is some OS standard (which aren't great to be followed blindly) If you just want to make your personal stuff do what you expect, then sure, by all means force everything to whatever you like, but that's not good general advice.
larusso 4y ago
Oh I‘m fighting the battle for a clean home directory for years. I even use a setup on macOS to set specific environment variables via systemd during login so I can link them into the .config directory. Only issue with my setup in general is that I can‘t just replicate it for other people. I moved .aws directory in .config/aws and I sometimes forget what the default for most tools is or where I helped the tool out to „find the right path“. I also make sure when writing scripts/cli tools to use the XDG spec. In rust I use the dirs crate for example. I even go so far to never hardcode it for my own config scripts/files just in case I think about going from ~/.config to ~/.my_configurations or whatever.
- moondev 4y ago
  macOS + systemd? If on Linux this tool allows you to move config dir and file locations transparently. Pretty neat. https://github.com/queer/boxxy https://github.com/queer/boxxy
  - larusso 4y ago
    Nice. Thanks for that. This is my launch agent. https://github.com/Larusso/dotfiles/blob/master/.config/yadm/alt/.config/launchd%23%23os.Darwin/LaunchAgents/local.environment.plist https://github.com/Larusso/dotfiles/blob/master/.config/yadm... The nice side effect is that Apps launched via Spotlight will also inherit the path etc since they all are owned by launchd in the end.
    - larusso 4y ago
      Edit: Sorry for the confusion with systemd I meant launchd. I always mix these up.
eliaspro 4y ago
To clean up your home-dir from .dotfiles, theres xdg-ninja [1] which assists you to make all your applications to follow the XDG specs. [1] https://github.com/b3nj5m1n/xdg-ninja https://github.com/b3nj5m1n/xdg-ninja
tooltower 4y ago
I have a very dumb question: why does the article use `find` with `printf` and depth specification, as opposed to the simpler `ls -a`? I'm assuming it has something to do with portability, but `ls -a` is already in POSIX. I'm a bit confused.
- deleted 4y ago
  [deleted]
- johnchristopher 4y ago
  Hmm. I think it's because `ls -a` will not visually differentiate between files and folders and will also show `.`and `..`. and will span contents over columns while find will return a line by found items. Or they are a show-off.
  - lovelymono 4y ago
    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 https://man7.org/linux/man-pages/man1/ls.1.html
    - yjftsjthsd-h 4y ago
      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)
      - lovelymono 4y ago
        https://pubs.opengroup.org/onlinepubs/009696899/utilities/ls.html 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.
        4y ago
zamubafoo 4y ago
I completely agree with the article that more people should use the spec. I already do this for all my personal projects and nothing drives me up the wall more than seeing random config files strewn about. It also provides an easy target for freeing disk space if you do run into issues (just `rm -r $XDG_CACHE_HOME`). That said, I do think the spec would be improved by defining what constitutes a "user-specific data file" and how that is different from a "user-specific state file". Wouldn't "user-specific data files" just be "files" from a users perspective? I like the idea they have for this, but it's kind of under defined. Though that's probably a good thing because no one wants a ontological tome to wade through when working on a bash script or the like.
agnos 4y ago
How did OP manage to get rid of ~/.mozilla? It's the only offending dotfile left in my $HOME and the stickiest. Until Mozilla fixes their 19-year-old feature request to support XDG [1], I couldn't find a workaround that wasn't a total hack. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356 https://bugzilla.mozilla.org/show_bug.cgi?id=259356
- happymellon 4y ago
  Would this work? https://github.com/queer/boxxy https://github.com/queer/boxxy [Edit] woops, I didn't notice that it is linked right at the bottom.
goombacloud 4y ago
There is a changed version that includes drop-in config files, masking, and loading defaults from /usr/ instead of requiring full config files to live under /etc: https://uapi-group.org/specifications/specs/base_directory_specification/ https://uapi-group.org/specifications/specs/base_directory_s...
- gioele 4y ago
  There is work going on at freedesktop to standardize drop-in config files: «basedir: support separate (vendor/local) trees and masking for config files» https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/59 https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request... «basedir: support drop-ins for configuration paths» https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/60 https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...
- account42 4y ago
  This is much less general since what it means to merge configuration files is extremely domain specific.
jojo14 4y ago
XDG specs are crap. Sure one single ~/.config folder is a very good idea. But I want it clearly visible such as ~/config. But I don't want an additional and confusing ~/.local. Plus I don't want ~/Videos or ~/Pictures folders. I am not dumb. Let me organize my folders according to my needs and my will. The first thing I do when I setup a user account is removing those useless XDG folders. XDG pretend to remove folder clusterfuck then why do they add their crappy folders?
- jenadine 4y ago
  > 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.
  - justeleblanc 4y ago
    > That's not in the XDG spec. But it is. In the XDG user dir spec.
    - jbaber 4y ago
      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.
      - sam_lowry_ 4y ago
        I already posted this above, but here is a repost, because I know exactly how you feel: cat ~/.config/user-dirs.dirs XDG_DESKTOP_DIR="$HOME/.Desktop" XDG_DOWNLOAD_DIR="$HOME/tmp" XDG_TEMPLATES_DIR="$HOME/tmp" XDG_PUBLICSHARE_DIR="$HOME/tmp" XDG_DOCUMENTS_DIR="$HOME/tmp" XDG_MUSIC_DIR="$HOME/tmp" XDG_PICTURES_DIR="$HOME/tmp" XDG_VIDEOS_DIR="$HOME/tmp" Note that XDG_DESKTOP_DIR and XDG_DOWNLOAD_DIR have to point to different directories. In hindsight, this is obvious, but this is also a really stupid "security" bug-o-feature that costed countless hours to countless people.
jenadine 4y ago
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/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178 https://github.com/rust-lang/cargo/pull/9178
- senden9 4y ago
  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.
- happymellon 4y ago
  I put it in another comment, but if you are Rusting on Linux, you can use boxxy to fix bad behaving applications. https://github.com/queer/boxxy https://github.com/queer/boxxy
- agilob 4y ago
  Somebody should tell this to go people. They just create me a non-hidden directory `~/go`
  - vetinari 4y ago
    export GOPATH=~/Projects/go Has been like this since forever.
    - xdennis 4y ago
      Being like that for a long time is not a justification for terrible defaults.
      - pasc1878 4y ago
        That is a better default than a hidden directory. It is obvious and so you can set GOPATH Also works better on Windows where .path is not hidden Also it seems Rob Pike one of the creators of Go and involved with early UNIX thinks that . making hidden files was a mistake. Quote via XahLee http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_filename.html http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_... - original was Google+ so not existing now.
BiteCode_dev 4y ago
It's important on any system, not just XDG. The OS will assume you do, and offer features based on it, such as cleaning cache dirs, emptying temp dirs, etc. It's not just about being tidy, although it's important. But remembering all that stuff is annoying. If you use Python, the wonderful "appdirs" package will make using the best dir for the job on Windows, Mac and Linux, easy and transparent: https://pypi.org/project/appdirs/ https://pypi.org/project/appdirs/ I wish it was part of the stdlib. Another thing that grind my gears is people putting files inside their code project folder for development. It should be something configurable, that by default use the OS dir for prod, and "../var" dir with everything on it in dev. Less gitignore trouble, let's watcher overhead, less indexing for nothing, less clutter in file explorers, less possibility for errors. But you need to provide an easy way to locate those files, such as a cmd line entrypoints, otherwise it's painful.
- sscherfke 4y ago
  appdirs has officially been deprecated. Its successor is https://pypi.org/project/platformdirs/ https://pypi.org/project/platformdirs/
- spott 4y ago
  Except neither appdirs or platformdirs obey xdg on Mac, without an option to override. Which makes this less than ideal.
PrayagS 4y ago
https://github.com/b3nj5m1n/xdg-ninja https://github.com/b3nj5m1n/xdg-ninja This utility has been a lifesaver to clean up my home directory.
okasaki 4y ago
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 config dir, which you don't want to carry to the next install (which will have different versions, so probably a different default config) because that might break stuff. In the end you have to carefully look over all the configuration to see what's worthwhile to take with you, and it doesn't really matter if that's in ~/.appname or ~/.config/appname
- Arch-TK 4y ago
  > 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/ 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/ 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/ 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.
johnchristopher 4y ago
Oh yeah, I used to do that and diligently configured vim and others apps to use $XDG_{DATA_HOME,CONFIG_HOME}. Lots of razor cuts and more maintenance annoyances, not worth the time. I reverted to using the defaults on each new machine I configure these days.
rtontic 4y ago
I actually just make my personal home directory in the root of the filesystem. So /me. If /root can have it, why can't I? It is my machine after all.
- xdennis 4y ago
  Exactly! Fixing /home/<user> is a lost cause. You can't get thousands of applications to follow a common sense standard. It's more pragmatic to not store the files you care about in the dumping ground that's /home/ .
  - pasc1878 4y ago
    Not all OSs let alone all Unix OS have your home directory in /home so that is even less useful than xdg
- teddyh 4y ago
  Beware that any directory other than one under /home might not enjoy the same protections by default by other programs, like systemd’s ProtectHome setting. You’ll also probably want to adjust some settings, like AppArmor’s @{HOMEDIRS} setting.
  - kps 4y ago
    Does systemd really hardcode "/home" rather than use the user's actual home directory?
    - teddyh 4y ago
      Systemd needs the common parent directory of the home directory of all users on the system, in order to protect all user home directories from services. There is no “the” user.
      - kps 4y ago
        I did misplace the apostrophe. There is no guaranteed common parent directory of all users other than `/`.
hamdouni 4y ago
I see some comments about users having a hard time cleaning their home directory and advices to use tools (boxxy?). But I read this post as an advice for developers not for users. A long crusade for standardisation may I say ;-)
quicklime 4y ago
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.
- Oxodao 4y ago
  .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" :/
  - ajsnigrutin 4y ago
    > 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.
    - Oxodao 4y ago
      That was a bit exaggerated I never clean fully the cache, mostly just specific apps but as long as I have everything closed (GUI and CLI apps), I don't really care what background services are doing and if they get upset because of this. I'm not on a server, that's my laptop so there is no critical stuff going on and once the app I use are closed that's good enough
fweimer 4y ago
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).
jbaber 4y ago
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.
- voltaireodactyl 4y ago
  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.
mugr 4y ago
I also find it very daunting having lying around all sorts of history files I never use like bash, wget and even less.
upofadown 4y ago
Yeah, we have a straightforward and widely established standard. Just put the related files in .programname . Now let's bikeshed and scatter them randomly across several places. To make it more fun let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file. Add lots of categories to create ambiguity. Make some of the default locations single level and others multiple level directories for no apparent reason for extra fun.
- weberer 4y ago
  >let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file What? Just use the environment variable when reading.
- account42 4y ago
  That has never been a standard as many programs have multiple dotfiles in ~. But even if it was, there are still good arguments for the XDG Basedir Spec: common way to change the location via environement variables as well as ability to split cache and non-cache.
  - simiones 4y ago
    Having this depend on env vars is an anti-feature in my mind. It's much harder to ensure env vars are set to the "right" values in all situations then it is to just use some well-known paths.
    - yesco 4y ago
      Come on, you just use a fallback if it's unset, you can even use your "well-known" paths for that if you want to. Don't pretend this harder than it actually is! This is like lesson 1 to using environmental variables, it's like saying you never free your mallocs because it's "much harder" that way! The OP site even provides code examples for popular languages, how can you imply that randomly littering your user's $HOME directory is the viable alternative here?
jannes 4y ago
On macOS there is also this standard: ~/Library/Application Support/AppName With 3 competing standards it's unlikely that this will ever be resolved.
alphazard 4y ago
I'll take the other side of this. We have this concept of applications being "well behaved" if they only read and write from parts of the filesystem that users expect. The XDG directories are what most linux and macOS users expect, even if they don't know about the standard. This well-behavedness feeds into the larger idea of high quality software. Hiqh quality means users are more likely to recommend it, engineers are more likely to respect the application's authors, etc. The problem with this is that it's all socially enforced, but it's not a social problem, it's a technical problem. The issue isn't that we haven't put enough pressure on developers to read the correct environment variables. It's that we have such a poor isolation story on UNIX that we have to care about where applications read and write from, rather than letting them do whatever they want in a sandbox. Many of the open source docker images are on the right track here. Where does the persistent state go? /data. Where does the configuration go? /config. Where does the cached data go? /cache. All in the most obvious places right at the filesystem root. Those applications would be considered "badly behaved" outside the container, but inside, it's much easier to predict what they will do.
- MawKKe 4y ago
  Exactly. It feels foolish to demand N unrelated applications implement support for the same arbitrary ruleset N different times. Why must applications incorporate implementation details of the deployment environment? Why does the environment owner not have tooling to control where files are placed?
  - redeeman 4y ago
    because the application is trusted with a powerful API, that emparts some obligations on whomever wields it not to do bullshit that shouldnt be done. This trust is in some cases clearly not earned, and so one might consider that some applications are not worthy of having access to these APIs
- account42 4y ago
  You can't technically enforce an application to cleanly split cache and configuration data and you will probably already fail to enforce splitting application data and user data for applications that need to access user data. Technical enforcement is also not free - it has both a performance and usability cost at applies to everyone not just bad actors. One of the things I like about free software is that it allows for high trust environments because you don't need technical restrictions but can instead rely on people not being dicks. I consider this similar to wanting to live in places where I don't have to worry about locking my doors and closing all windows every time I go to the store.
sam_lowry_ 4y ago
XDG sucks for the only reason that it is really difficult to configure user directories to one's taste. For instance, to get rid of Download, Templates, Desktop, Public Share, Documents, Music, Pictures, Videos directories I not only have to point them to somewhere else, I also have to make sure Desktop and Download do not point to the same directory, otherwise my config will not be used. Here, after literally hours of researching, I figured the config that works: cat ~/.config/user-dirs.dirs XDG_DESKTOP_DIR="$HOME/.Desktop" XDG_DOWNLOAD_DIR="$HOME/tmp" XDG_TEMPLATES_DIR="$HOME/tmp" XDG_PUBLICSHARE_DIR="$HOME/tmp" XDG_DOCUMENTS_DIR="$HOME/tmp" XDG_MUSIC_DIR="$HOME/tmp" XDG_PICTURES_DIR="$HOME/tmp" XDG_VIDEOS_DIR="$HOME/tmp"
- account42 4y ago
  The XDG user dirs are not part of the XDG basedir spec.
moasda 4y ago
Lazarus (https://www.lazarus-ide.org/ https://www.lazarus-ide.org/) has built-in support for the configuration folder ($XDG_CONFIG_HOME) in the user context and in the global context: GetAppConfigDir() and GetAppConfigFile() For more details see https://wiki.lazarus.freepascal.org/Multiplatform_Programming_Guide#Configuration_files https://wiki.lazarus.freepascal.org/Multiplatform_Programmin...
PhilipRoman 4y ago
I just wish they didn't needlessly introduce asymmetry with new names like .config. What's wrong with .local/etc?
throw7 4y ago
How about you stay out of my damn house? I'm pretty sure I popped a vessel the day these freakin' directories spammed my home directory.
fs111 4y ago
Back in the old days I could delete `.<whatever>` and reset a program to its defaults. Now I have to navigate through `.config` and try to find where stuff is. How is this better?
- aerfio 4y ago
  cd .config -> apply the first sentence again
- wink 4y ago
  No change, programs old and new should document where they litter their files. And if they do, you'll easily notice where in .config it will be.
ploum 4y ago
I was trying to lobby for those exactly… 14 years ago! https://ploum.net/207-modify-your-application-to-use-xdg-folders/index.html https://ploum.net/207-modify-your-application-to-use-xdg-fol... Some things never change…
AnIdiotOnTheNet 4y ago
Considered opinion from decades of desktop computer usage: Trying to use paths to meaningfully separate data by type is a fool's errand and no one will ever get it "right". It is the primary thing UNIX systems got extremely wrong that not only holds them back in the personal desktop space, but through cultural cross pollination has been ruining other desktop OSs too. Original single-user desktop OSs had the best solution: keep everything related to the application functionality with the application. The application (in AppDir/file with resource fork/whatever form) itself can be wherever the user feels like putting it, and saved documents go wherever the hell the user feels like putting them. The only exception should be cache and temp data, which should go somewhere global. This has the benefit of being clear and obvious to the user. The obvious objections: > but multiuser! Is a use case that basically doesn't exist in personal desktop space. To the extent it was ever a useful concept it was during a time when a desktop computer was the only way to access the internet and they were too expensive and bulky to justify more than one in a home. Even then, we managed fine without OS level multiuser support. To the extent that anything like a multiuser desktop exists it is certainly a niche, and therefore we should handle its problems with virtualization, containerization, filesystem overlay hackery, etc. > but ease of backup! Depends entirely on what cross section of things you care about backing up. As it is you already have to search dozens of places for including what you want and have rules for excluding what you don't and no standard is ever going to fix that. Applying those same things to the "everything with the application" model is, at worst, not any worse than things already are. > but if I copy the application, it also copies the config. That's a decent point, but I would argue this is the obvious thing and also perhaps what is intended. Solution is to have a standardized mechanism of clearing out the config and other state from the application directory, such that it can be done with a right-click context menu. A factory reset of the application if you will. > but I never use a mouse and only use the GUI as a really fancy tmux That's fine, nothing about this model makes your life conceptually any harder. Keep all the applications in directories in your PATH. Factory reset of the application can be just as easily done with a command as a context menu entry. You can still put applications in repos and even overengineer a package manager for them if you really want to.
cassepipe 4y ago
Once upon a time, there was a distribution called GoboLinux https://gobolinux.org/ https://gobolinux.org/
butz 4y ago
Does Flatpak solve this issue to some point, at least when using fully sandboxed apps?
kkfx 4y ago
A small note I do not have seen so far in comments here: the article told about "easier backup", actually I strongly disagree. I do keep some configs I've write myself/edited myself. Most of the rest are automatically made stuff useless to be backed up and sometimes also inopportune to restore since a version to another some (cr)applications do badly digest their own automatic config.
transfire 4y ago
I have been a staunch supporter of XDG basedir standard for many years. Unfortunately it has become clear to me that it is simply not enough. So instead I have started to abandon home as the place to store my files. I use a subdirectory in home instead, the name of which is purposefully non-specific.
julesontour2 4y ago
[dead]
whatsinaname1 4y ago
[dead]
gypsysoul09 4y ago
[dead]
pinchofsalt 4y ago
[dead]
candidcaptures2 4y ago
[dead]
doyouevenlift1 4y ago
[dead]
whatsthetea1 4y ago
[dead]
hairofthejog1 4y ago
[dead]
alwaysinblack 4y ago
[dead]
thoughtcatalog 4y ago
[dead]
dietprada33 4y ago
[dead]
wokeprincess 4y ago
[dead]
angelhearts2 4y ago
[dead]

275 points by hyperupcall 4y ago

Yes! Some projects are stuck for years trying to implement this. Firefox for example. > .audacity-data Recent Audacity already fixed this.

encryptluks2 4y ago
[dead]

fiddlerwoaroof 4y ago

I strongly disagree: the dot files cause very little inconvenience because they’re typically hidden and they’re easier to type and list than the XDG spec stuff

OJFord 4y ago
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.
- lmm 4y ago
  > The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better? Because it puts them in an overengineered, overly cumbersome hierarchy under that. It reminds me of OSI. > 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. Either of the first two is easier to work with than the XDG-compliant way, and the last is no harder.
  - memetomancer 4y ago
    FYI, and nothing personal, but your comment is more or less coming across to me as "whelp, the inflexible delegation has spoken". I go to great lengths to maintain a flexible mindset, to try to get the best out of a new approach. Hearing/reading someone trying to throw a shallow take-down of something they haven't tried doesn't read as "ooh that person is so cool I'm super convinced"... it comes across more like "oh, poor fella went and got his brain rigidized... and at such a young age". But maybe you'll come around. Maybe people will come around and realize the ankle-deep hot takes are worse than useless and we can all get back to the good stuff. On the other hand, I do have my own suspicions. At first glance it does simply sound like another layer of idiosyncrasy to jam into the memory hole, something that will certainly never be universally adopted and just add more hidey-holes to search for config files. But, as I hope I made clear, I'm willing to give it a shot because I don't trust myself to have absolute insight into a thing after a couple minutes reading. There may well be aspects to this that I can't conjure, but will really like after all is said and done.
    - lmm 4y ago
      > 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?
      - chimprich 4y ago
        > 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?
        rkta 4y ago
        > 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/?
- comex 4y ago
  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. If I don't know where the configuration is already, I have to check all of them. I know ~/.local/share is supposed to be for "data files" and ~/.config is supposed to be for "configuration files", but in practice the distinction seems to be rather unclear. Also, ~/.local/share/foo is a lot slower to type than ~/.foo even with tab completion. Why does that path need to be two directories deep? ~/.config/foo is less bad but still slower.
  - account42 4y ago
    With the XDG Basedir Spec you don't have to use ~/.local/share and ~/.config if you don't like them, they are just the defaults after all and you can set the respective environment variables to whatever you want. That is not an option you had before. Admittedly, it would have been nice if the variables were defined in a way that let you reproduce the traditional dotfiles, e.g. by pasting $XDG_DATA_HOME in front of the app name so you could set XDG_DATA_HOME=$HOME/. and requiring an explicit trailing slash if you want them to be a directory.
  - OJFord 4y ago
    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.
    - benatkin 4y ago
      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.
deadbunny 4y ago
vi .co[tab]app[tab] is much easier to remember and type when everything is in the right place.
kristopolous 4y ago
Isn't it great that it's optional? I love how Linux is like that. We can all be happy
- fiddlerwoaroof 4y ago
  Except it isn't because I don't pick the configuration scheme for every program I use.
benatkin 4y ago
You're in good company! Most of the apps listed used a hidden file or directory in the home directory.
sigmonsays 4y ago
i agree too, All i've seen is a mess of conflicting standards. Is the dotfile now in ~/.local, or ~/.config or what?
- yjftsjthsd-h 4y ago
  It should be in $XDG_DATA_HOME/app/
- pasc1878 4y ago
  It depends on what the dotfile is for. If configuration then ~/.config. (which could be empty if you just use the default setup) If for data that the app writes then ~/.local
eviks 4y ago
The hidden part is another usability mistake, but the main benefit of XDG is respecting user's choice who can set an env var to avoid the mess, hope you wouldn't disagree with an option the improves someone's life without affecting yours in any way?
- fiddlerwoaroof 4y ago
  The convention of hiding files starting with a dot is not a usability mistake. It’s a usability improvement.
  - eviks 4y ago
    Why would you hide the files a user is explicitly expected to tweak to configure an app's behavior and call it an improvement??? It degrades the config experience, what part of "usability" is improved? Also, fun historical fact: it was a bug when it was implemented https://linux-audit.com/linux-history-how-dot-files-became-hidden-files/ https://linux-audit.com/linux-history-how-dot-files-became-h...
pantalaimon 4y ago
It’s much easier to back up/certain config files when they are all in one place.

kitsunesoba 4y ago

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.

drunkpotato 4y ago
Luckily if you’re a developer on MacOS, you can have that too! In addition to ~/.config and a million .dotfiles and .dotdirectories from decades of unixy tools! Truly a cornucopia.
- kitsunesoba 4y ago
  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.
  - petesergeant 4y ago
    Do any of the Linux distros do this? Strikes me as the kind of thing Debian would do for everything in apt
    - gjvc 4y ago
      Do you have any examples of Debian doing this?
      - petesergeant 4y ago
        Sure. In software of mine distributed by Debian, there's usually a "debian/patches" directory, that I didn't add, that's changes the Debian project wanted to make to the system. I'm sure there's a formal name for that system. Most Debian packages seem to have one.
  - 4y ago

prussian 4y ago

I'd say for windows, you'd probably want to define them as well since a lot of ports will use HOME, XDG_* and other non-windowsy environment variables anyhow.

justeleblanc 4y ago
Those are shitty ports. The worst are those who will plop something in a dot file in your home directory. They don't get hidden on windows, people!

Eduard 4y ago

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

saghm 4y ago
> 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).
chungy 4y ago
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 4y ago
  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.

WiSaGaN 4y ago

If you are using Rust, you can easily conform to this by using `directories` crate: https://docs.rs/directories/latest/directories/struct.BaseDirs.html https://docs.rs/directories/latest/directories/struct.BaseDi...

CameronNemo 4y ago
I am not going to look it up for every language, but you can safely assume all major languages have a similar library to make this easy.
justeleblanc 4y ago
Rust itself doesn't care and puts cargo and rustup in your home.
deleted 4y ago
[deleted]

rektide 4y ago

One of the things that changed my life recently, that I hadn't seen before: NeoVim has a NVIM_APPNAME variable that lets you change the app name. So when I wanted to try AstroVim, I just set NVIM_APPNAME=astrovim, and dropped the files in ~/.config/astrovim instead of blowing up my existing (shitty) ~/.config/nvim. I really wish the idea of configurable appnames was a part of the spec! (or a well-known extension!)

kzrdude 4y ago
It's a very recent neovim feature, so it has not been around to discover for that long
- rektide 4y ago
  Yes, it's only a month old! https://github.com/neovim/neovim/pull/22128 https://github.com/neovim/neovim/pull/22128 I actually have something similar in some of my old old projects. And I'd expect I ripped the idea off from somewhere. But I don't know who to cite. :(
Oxodao 4y ago
Thanks for this tips! Didn't knew it either
kps 4y ago
Historically a lot of programs would use argv[0] as their name. Vi-family editors do have an excuse not to do that, since vi uses its name for other purposes, e.g. `view` for readonly.

rapiz 4y ago

I have been long expecting a daemon that picks up scattered config files and make soft links to ~/.config

000ooo000 4y ago

In what world is simply dumping config items for your app in the user's home directory sensible? Why stop at config items? Do cache or temp crap too. The thought process of persisting with this baffles me. Microsoft would be absolutely ridiculed if one day your msword preferences appeared on your desktop as an XML file, and no matter what, it kept reappearing.

heywoodlh 4y ago
Yeah, although, I'm not a huge fan of Microsoft's default config file locations either. Some examples: - PowerShell Core's default profile is in $HOME\Documents\PowerShell -- or if you have OneDrive enabled, $HOME\OneDrive\Documents\PowerShell. - Windows Terminal is $HOME\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json. I can feel pretty confident assuming that if Microsoft can place their power users' config files for Microsoft's Terminal and Microsoft's primary shell in seemingly unrelated locations and not get huge complaints, I would imagine that most Windows users are probably not people who would ridicule Microsoft for placing an XML file in their home directory. EDIT: I used these examples specifically, because a Terminal Emulator and shell profile are the exact kind of apps you would store configs for in a dotfiles repo.
- delta_p_delta_x 4y ago
  Microsoft (and subsidiaries, e.g. 343 Industries), is somehow even worse at adhering to its own norms. Now, I have .vscode and .dotnet folders in the top level of %USERPROFILE%. Even Visual Studio creates a stupid %USERPROFILE%\source\repos directory tree, when I never told it to. I am fed up by this, and have completely given up on maintaining the tidiness of my %USERPROFILE% and %USERPROFILE\Documents. Almost all video games have absolutely no respect whatsoever for OS norms, and just spew their config and save data all over the damn place in %USERPROFILE%\<game title>, %USERPROFILE%\My Games\<game title>, %USERPROFILE%\<developer or publisher>\<game title>. The worst thing is that Windows has a place specifically for video game saves: %USERPROFILE%\Saved Games, or programmatically in C/C++: `SHGetKnownFolderPath(FOLDERID_SavedGames, ...)`. To add to the mix, I also have GNU/Linux-first programs like SSH, Gradle, etc that just straight-up create dot-directories and dotfiles in the top level of %USERPROFILE%. Windows is not Unix/Linux; a dot prefix does not mean 'hidden'. Windows has an explicit 'hidden' filesystem metadata tag that programmers need to (and frequently forget to) set: `SetFileAttributesA(filePath, FILE_ATTRIBUTE_HIDDEN)`. Home, not so sweet home.

olalonde 4y ago

In case anyone else was wondering, XDG stands for X Desktop Group, an older name for freedesktop.org[0]. [0] https://en.wikipedia.org/wiki/Freedesktop.org https://en.wikipedia.org/wiki/Freedesktop.org

kelnos 4y ago
Oh huh, I was always under the impression that "X" meant "Cross", as in "Cross-Desktop Group", since they were working on standardizing things across different desktop environments. But I guess the "X" was just a reference to X11? I guess today it encompasses a lot more than X11-based stuff, though...

eviks 4y ago

Weird how this promotional article is weak re advice for the most popular OS (and personal experience isn't the only source of insight)

yjftsjthsd-h 4y ago
> for the most popular OS Android doesn't really do dot files. Or config files that the user can see at all. (And if you'd like to amend to "the most used desktop OS", this is obviously aimed at unix-likes, but actually Windows does have an equivalent standard and programs targeting that platform really should be following it just like programs targeting unix-likes really should follow this)
- eviks 4y ago
  Just like it's obvious what OS I meant, it's also obvious that the article's aim is not as narrow as you're trying to paint it, otherwise it wouldn't have a section on Windows. And the Mac section is also weak, so even that is not a good excuse; and Mac also has a standard, and it's best to ignore it if a user sets an XDG env var 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 to the same ~/.config, e.g., it's much easier to do backup, and I don't care that there is some OS standard (which aren't great to be followed blindly) But even for non x-platform apps that Windows AppData defaults are a dumping ground for app data (not configs) I don't care about and don't need to backup or anything , so if there is an option to put some configs that are more important in a different folder, that's better
  - yjftsjthsd-h 4y ago
    > 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 to the same ~/.config, e.g., it's much easier to do backup, and I don't care that there is some OS standard (which aren't great to be followed blindly) If you just want to make your personal stuff do what you expect, then sure, by all means force everything to whatever you like, but that's not good general advice.

larusso 4y ago

Oh I‘m fighting the battle for a clean home directory for years. I even use a setup on macOS to set specific environment variables via systemd during login so I can link them into the .config directory. Only issue with my setup in general is that I can‘t just replicate it for other people. I moved .aws directory in .config/aws and I sometimes forget what the default for most tools is or where I helped the tool out to „find the right path“. I also make sure when writing scripts/cli tools to use the XDG spec. In rust I use the dirs crate for example. I even go so far to never hardcode it for my own config scripts/files just in case I think about going from ~/.config to ~/.my_configurations or whatever.

moondev 4y ago
macOS + systemd? If on Linux this tool allows you to move config dir and file locations transparently. Pretty neat. https://github.com/queer/boxxy https://github.com/queer/boxxy
- larusso 4y ago
  Nice. Thanks for that. This is my launch agent. https://github.com/Larusso/dotfiles/blob/master/.config/yadm/alt/.config/launchd%23%23os.Darwin/LaunchAgents/local.environment.plist https://github.com/Larusso/dotfiles/blob/master/.config/yadm... The nice side effect is that Apps launched via Spotlight will also inherit the path etc since they all are owned by launchd in the end.
  - larusso 4y ago
    Edit: Sorry for the confusion with systemd I meant launchd. I always mix these up.

eliaspro 4y ago

To clean up your home-dir from .dotfiles, theres xdg-ninja [1] which assists you to make all your applications to follow the XDG specs. [1] https://github.com/b3nj5m1n/xdg-ninja https://github.com/b3nj5m1n/xdg-ninja

tooltower 4y ago

I have a very dumb question: why does the article use `find` with `printf` and depth specification, as opposed to the simpler `ls -a`? I'm assuming it has something to do with portability, but `ls -a` is already in POSIX. I'm a bit confused.

deleted 4y ago
[deleted]
johnchristopher 4y ago
Hmm. I think it's because `ls -a` will not visually differentiate between files and folders and will also show `.`and `..`. and will span contents over columns while find will return a line by found items. Or they are a show-off.
- lovelymono 4y ago
  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 https://man7.org/linux/man-pages/man1/ls.1.html
  - yjftsjthsd-h 4y ago
    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)
    - lovelymono 4y ago
      https://pubs.opengroup.org/onlinepubs/009696899/utilities/ls.html 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.
      - 4y ago

zamubafoo 4y ago

I completely agree with the article that more people should use the spec. I already do this for all my personal projects and nothing drives me up the wall more than seeing random config files strewn about. It also provides an easy target for freeing disk space if you do run into issues (just `rm -r $XDG_CACHE_HOME`). That said, I do think the spec would be improved by defining what constitutes a "user-specific data file" and how that is different from a "user-specific state file". Wouldn't "user-specific data files" just be "files" from a users perspective? I like the idea they have for this, but it's kind of under defined. Though that's probably a good thing because no one wants a ontological tome to wade through when working on a bash script or the like.

agnos 4y ago

How did OP manage to get rid of ~/.mozilla? It's the only offending dotfile left in my $HOME and the stickiest. Until Mozilla fixes their 19-year-old feature request to support XDG [1], I couldn't find a workaround that wasn't a total hack. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356 https://bugzilla.mozilla.org/show_bug.cgi?id=259356

happymellon 4y ago
Would this work? https://github.com/queer/boxxy https://github.com/queer/boxxy [Edit] woops, I didn't notice that it is linked right at the bottom.

goombacloud 4y ago

There is a changed version that includes drop-in config files, masking, and loading defaults from /usr/ instead of requiring full config files to live under /etc: https://uapi-group.org/specifications/specs/base_directory_specification/ https://uapi-group.org/specifications/specs/base_directory_s...

gioele 4y ago
There is work going on at freedesktop to standardize drop-in config files: «basedir: support separate (vendor/local) trees and masking for config files» https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/59 https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request... «basedir: support drop-ins for configuration paths» https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/60 https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...
account42 4y ago
This is much less general since what it means to merge configuration files is extremely domain specific.

jojo14 4y ago

XDG specs are crap. Sure one single ~/.config folder is a very good idea. But I want it clearly visible such as ~/config. But I don't want an additional and confusing ~/.local. Plus I don't want ~/Videos or ~/Pictures folders. I am not dumb. Let me organize my folders according to my needs and my will. The first thing I do when I setup a user account is removing those useless XDG folders. XDG pretend to remove folder clusterfuck then why do they add their crappy folders?

jenadine 4y ago
> 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.
- justeleblanc 4y ago
  > That's not in the XDG spec. But it is. In the XDG user dir spec.
  - jbaber 4y ago
    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.
    - sam_lowry_ 4y ago
      I already posted this above, but here is a repost, because I know exactly how you feel: cat ~/.config/user-dirs.dirs XDG_DESKTOP_DIR="$HOME/.Desktop" XDG_DOWNLOAD_DIR="$HOME/tmp" XDG_TEMPLATES_DIR="$HOME/tmp" XDG_PUBLICSHARE_DIR="$HOME/tmp" XDG_DOCUMENTS_DIR="$HOME/tmp" XDG_MUSIC_DIR="$HOME/tmp" XDG_PICTURES_DIR="$HOME/tmp" XDG_VIDEOS_DIR="$HOME/tmp" Note that XDG_DESKTOP_DIR and XDG_DOWNLOAD_DIR have to point to different directories. In hindsight, this is obvious, but this is also a really stupid "security" bug-o-feature that costed countless hours to countless people.

jenadine 4y ago

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/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178 https://github.com/rust-lang/cargo/pull/9178

senden9 4y ago
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.
happymellon 4y ago
I put it in another comment, but if you are Rusting on Linux, you can use boxxy to fix bad behaving applications. https://github.com/queer/boxxy https://github.com/queer/boxxy
agilob 4y ago
Somebody should tell this to go people. They just create me a non-hidden directory `~/go`
- vetinari 4y ago
  export GOPATH=~/Projects/go Has been like this since forever.
  - xdennis 4y ago
    Being like that for a long time is not a justification for terrible defaults.
    - pasc1878 4y ago
      That is a better default than a hidden directory. It is obvious and so you can set GOPATH Also works better on Windows where .path is not hidden Also it seems Rob Pike one of the creators of Go and involved with early UNIX thinks that . making hidden files was a mistake. Quote via XahLee http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_filename.html http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_... - original was Google+ so not existing now.

BiteCode_dev 4y ago

It's important on any system, not just XDG. The OS will assume you do, and offer features based on it, such as cleaning cache dirs, emptying temp dirs, etc. It's not just about being tidy, although it's important. But remembering all that stuff is annoying. If you use Python, the wonderful "appdirs" package will make using the best dir for the job on Windows, Mac and Linux, easy and transparent: https://pypi.org/project/appdirs/ https://pypi.org/project/appdirs/ I wish it was part of the stdlib. Another thing that grind my gears is people putting files inside their code project folder for development. It should be something configurable, that by default use the OS dir for prod, and "../var" dir with everything on it in dev. Less gitignore trouble, let's watcher overhead, less indexing for nothing, less clutter in file explorers, less possibility for errors. But you need to provide an easy way to locate those files, such as a cmd line entrypoints, otherwise it's painful.

sscherfke 4y ago
appdirs has officially been deprecated. Its successor is https://pypi.org/project/platformdirs/ https://pypi.org/project/platformdirs/
spott 4y ago
Except neither appdirs or platformdirs obey xdg on Mac, without an option to override. Which makes this less than ideal.

PrayagS 4y ago

https://github.com/b3nj5m1n/xdg-ninja https://github.com/b3nj5m1n/xdg-ninja This utility has been a lifesaver to clean up my home directory.

okasaki 4y ago

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 config dir, which you don't want to carry to the next install (which will have different versions, so probably a different default config) because that might break stuff. In the end you have to carefully look over all the configuration to see what's worthwhile to take with you, and it doesn't really matter if that's in ~/.appname or ~/.config/appname

Arch-TK 4y ago
> 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/ 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/ 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/ 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.

johnchristopher 4y ago

Oh yeah, I used to do that and diligently configured vim and others apps to use $XDG_{DATA_HOME,CONFIG_HOME}. Lots of razor cuts and more maintenance annoyances, not worth the time. I reverted to using the defaults on each new machine I configure these days.

rtontic 4y ago

I actually just make my personal home directory in the root of the filesystem. So /me. If /root can have it, why can't I? It is my machine after all.

xdennis 4y ago
Exactly! Fixing /home/<user> is a lost cause. You can't get thousands of applications to follow a common sense standard. It's more pragmatic to not store the files you care about in the dumping ground that's /home/ .
- pasc1878 4y ago
  Not all OSs let alone all Unix OS have your home directory in /home so that is even less useful than xdg
teddyh 4y ago
Beware that any directory other than one under /home might not enjoy the same protections by default by other programs, like systemd’s ProtectHome setting. You’ll also probably want to adjust some settings, like AppArmor’s @{HOMEDIRS} setting.
- kps 4y ago
  Does systemd really hardcode "/home" rather than use the user's actual home directory?
  - teddyh 4y ago
    Systemd needs the common parent directory of the home directory of all users on the system, in order to protect all user home directories from services. There is no “the” user.
    - kps 4y ago
      I did misplace the apostrophe. There is no guaranteed common parent directory of all users other than `/`.

hamdouni 4y ago

I see some comments about users having a hard time cleaning their home directory and advices to use tools (boxxy?). But I read this post as an advice for developers not for users. A long crusade for standardisation may I say ;-)

quicklime 4y ago

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.

Oxodao 4y ago
.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" :/
- ajsnigrutin 4y ago
  > 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.
  - Oxodao 4y ago
    That was a bit exaggerated I never clean fully the cache, mostly just specific apps but as long as I have everything closed (GUI and CLI apps), I don't really care what background services are doing and if they get upset because of this. I'm not on a server, that's my laptop so there is no critical stuff going on and once the app I use are closed that's good enough

fweimer 4y ago

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

jbaber 4y ago

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.

voltaireodactyl 4y ago
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.

mugr 4y ago

I also find it very daunting having lying around all sorts of history files I never use like bash, wget and even less.

upofadown 4y ago

Yeah, we have a straightforward and widely established standard. Just put the related files in .programname . Now let's bikeshed and scatter them randomly across several places. To make it more fun let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file. Add lots of categories to create ambiguity. Make some of the default locations single level and others multiple level directories for no apparent reason for extra fun.

weberer 4y ago
>let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file What? Just use the environment variable when reading.
account42 4y ago
That has never been a standard as many programs have multiple dotfiles in ~. But even if it was, there are still good arguments for the XDG Basedir Spec: common way to change the location via environement variables as well as ability to split cache and non-cache.
- simiones 4y ago
  Having this depend on env vars is an anti-feature in my mind. It's much harder to ensure env vars are set to the "right" values in all situations then it is to just use some well-known paths.
  - yesco 4y ago
    Come on, you just use a fallback if it's unset, you can even use your "well-known" paths for that if you want to. Don't pretend this harder than it actually is! This is like lesson 1 to using environmental variables, it's like saying you never free your mallocs because it's "much harder" that way! The OP site even provides code examples for popular languages, how can you imply that randomly littering your user's $HOME directory is the viable alternative here?

jannes 4y ago

On macOS there is also this standard: ~/Library/Application Support/AppName With 3 competing standards it's unlikely that this will ever be resolved.

alphazard 4y ago

I'll take the other side of this. We have this concept of applications being "well behaved" if they only read and write from parts of the filesystem that users expect. The XDG directories are what most linux and macOS users expect, even if they don't know about the standard. This well-behavedness feeds into the larger idea of high quality software. Hiqh quality means users are more likely to recommend it, engineers are more likely to respect the application's authors, etc. The problem with this is that it's all socially enforced, but it's not a social problem, it's a technical problem. The issue isn't that we haven't put enough pressure on developers to read the correct environment variables. It's that we have such a poor isolation story on UNIX that we have to care about where applications read and write from, rather than letting them do whatever they want in a sandbox. Many of the open source docker images are on the right track here. Where does the persistent state go? /data. Where does the configuration go? /config. Where does the cached data go? /cache. All in the most obvious places right at the filesystem root. Those applications would be considered "badly behaved" outside the container, but inside, it's much easier to predict what they will do.

MawKKe 4y ago
Exactly. It feels foolish to demand N unrelated applications implement support for the same arbitrary ruleset N different times. Why must applications incorporate implementation details of the deployment environment? Why does the environment owner not have tooling to control where files are placed?
- redeeman 4y ago
  because the application is trusted with a powerful API, that emparts some obligations on whomever wields it not to do bullshit that shouldnt be done. This trust is in some cases clearly not earned, and so one might consider that some applications are not worthy of having access to these APIs
account42 4y ago
You can't technically enforce an application to cleanly split cache and configuration data and you will probably already fail to enforce splitting application data and user data for applications that need to access user data. Technical enforcement is also not free - it has both a performance and usability cost at applies to everyone not just bad actors. One of the things I like about free software is that it allows for high trust environments because you don't need technical restrictions but can instead rely on people not being dicks. I consider this similar to wanting to live in places where I don't have to worry about locking my doors and closing all windows every time I go to the store.

sam_lowry_ 4y ago

XDG sucks for the only reason that it is really difficult to configure user directories to one's taste. For instance, to get rid of Download, Templates, Desktop, Public Share, Documents, Music, Pictures, Videos directories I not only have to point them to somewhere else, I also have to make sure Desktop and Download do not point to the same directory, otherwise my config will not be used. Here, after literally hours of researching, I figured the config that works: cat ~/.config/user-dirs.dirs XDG_DESKTOP_DIR="$HOME/.Desktop" XDG_DOWNLOAD_DIR="$HOME/tmp" XDG_TEMPLATES_DIR="$HOME/tmp" XDG_PUBLICSHARE_DIR="$HOME/tmp" XDG_DOCUMENTS_DIR="$HOME/tmp" XDG_MUSIC_DIR="$HOME/tmp" XDG_PICTURES_DIR="$HOME/tmp" XDG_VIDEOS_DIR="$HOME/tmp"

account42 4y ago
The XDG user dirs are not part of the XDG basedir spec.

moasda 4y ago

Lazarus (https://www.lazarus-ide.org/ https://www.lazarus-ide.org/) has built-in support for the configuration folder ($XDG_CONFIG_HOME) in the user context and in the global context: GetAppConfigDir() and GetAppConfigFile() For more details see https://wiki.lazarus.freepascal.org/Multiplatform_Programming_Guide#Configuration_files https://wiki.lazarus.freepascal.org/Multiplatform_Programmin...

PhilipRoman 4y ago

I just wish they didn't needlessly introduce asymmetry with new names like .config. What's wrong with .local/etc?

throw7 4y ago

How about you stay out of my damn house? I'm pretty sure I popped a vessel the day these freakin' directories spammed my home directory.

fs111 4y ago

Back in the old days I could delete `.<whatever>` and reset a program to its defaults. Now I have to navigate through `.config` and try to find where stuff is. How is this better?

aerfio 4y ago
cd .config -> apply the first sentence again
wink 4y ago
No change, programs old and new should document where they litter their files. And if they do, you'll easily notice where in .config it will be.

ploum 4y ago

I was trying to lobby for those exactly… 14 years ago! https://ploum.net/207-modify-your-application-to-use-xdg-folders/index.html https://ploum.net/207-modify-your-application-to-use-xdg-fol... Some things never change…

AnIdiotOnTheNet 4y ago

Considered opinion from decades of desktop computer usage: Trying to use paths to meaningfully separate data by type is a fool's errand and no one will ever get it "right". It is the primary thing UNIX systems got extremely wrong that not only holds them back in the personal desktop space, but through cultural cross pollination has been ruining other desktop OSs too. Original single-user desktop OSs had the best solution: keep everything related to the application functionality with the application. The application (in AppDir/file with resource fork/whatever form) itself can be wherever the user feels like putting it, and saved documents go wherever the hell the user feels like putting them. The only exception should be cache and temp data, which should go somewhere global. This has the benefit of being clear and obvious to the user. The obvious objections: > but multiuser! Is a use case that basically doesn't exist in personal desktop space. To the extent it was ever a useful concept it was during a time when a desktop computer was the only way to access the internet and they were too expensive and bulky to justify more than one in a home. Even then, we managed fine without OS level multiuser support. To the extent that anything like a multiuser desktop exists it is certainly a niche, and therefore we should handle its problems with virtualization, containerization, filesystem overlay hackery, etc. > but ease of backup! Depends entirely on what cross section of things you care about backing up. As it is you already have to search dozens of places for including what you want and have rules for excluding what you don't and no standard is ever going to fix that. Applying those same things to the "everything with the application" model is, at worst, not any worse than things already are. > but if I copy the application, it also copies the config. That's a decent point, but I would argue this is the obvious thing and also perhaps what is intended. Solution is to have a standardized mechanism of clearing out the config and other state from the application directory, such that it can be done with a right-click context menu. A factory reset of the application if you will. > but I never use a mouse and only use the GUI as a really fancy tmux That's fine, nothing about this model makes your life conceptually any harder. Keep all the applications in directories in your PATH. Factory reset of the application can be just as easily done with a command as a context menu entry. You can still put applications in repos and even overengineer a package manager for them if you really want to.

cassepipe 4y ago

Once upon a time, there was a distribution called GoboLinux https://gobolinux.org/ https://gobolinux.org/

butz 4y ago

Does Flatpak solve this issue to some point, at least when using fully sandboxed apps?

kkfx 4y ago

A small note I do not have seen so far in comments here: the article told about "easier backup", actually I strongly disagree. I do keep some configs I've write myself/edited myself. Most of the rest are automatically made stuff useless to be backed up and sometimes also inopportune to restore since a version to another some (cr)applications do badly digest their own automatic config.

transfire 4y ago

I have been a staunch supporter of XDG basedir standard for many years. Unfortunately it has become clear to me that it is simply not enough. So instead I have started to abandon home as the place to store my files. I use a subdirectory in home instead, the name of which is purposefully non-specific.

julesontour2 4y ago

[dead]

whatsinaname1 4y ago

[dead]

gypsysoul09 4y ago

[dead]

pinchofsalt 4y ago

[dead]

candidcaptures2 4y ago

[dead]

doyouevenlift1 4y ago

[dead]