As written in the documentation, global settings are stored in $HOME/.fossil on Unix computers and in %LOCALAPPDATA%/_fossil on Windows computers.

The specifications of macOS tell us that such a file should probably go under $HOME/Library/Preferences and the XDG specifications for Linux tell us that it should go in $XDG_CONFIG_HOME (which defaults to $HOME/.config).

There has been a wide mouvement of ‘$HOME decluttering’ among many open source projects including git. Would it be possible to change Fossil default config file location?

I've been doing unix for 36 years, and I've never heard of any of this before. I glanced through the documentation, quickly, and my first impression is that this is all an attempt to make unix more "friendly" to point-and-click users, and the expense of command-line users. In other words, the $XDG goal is to support GUIs and applications that you downloaded from an App-Store. For those of us who were raised on Unix PWB (Programmers Work-Bench) and who view unix as the world's greated IDE, this seems like needless and pointless complication.

How badly does my initial impression miss the mark?

You have not missed the mark at all for any Unixen I know of. (I've used quite a few, starting with SCO running on a PDP-11.)

You would even be on the mark for "MacOS" (or whatever rock or animal it is now), if you were running on the real, BSD OS that is buried within it.

Those decluttering recommendations make some sense, when following them works to the benefit of people challenged by a mouse with more than one button. But since files and directory names with leading '.' are conventionally hidden from that cohort, I see no reason to depart from the now well-established convention on Unixen (and becoming established among Windows applications) where config data goes into a single ~/.whatever file or directory. It's simple, and the first place to look when you cannot find the docs or bother with them.

How badly does my initial impression miss the mark?

It's a shift in defaults over the past 20-ish years, mainly affecting macOS and Linux, rather than traditional Unix.

I wouldn't mind if Fossil behaved as OP suggested.

I originally thought we might have a problem with old posts/docs referring to ~/.fossil but there really isn't a whole lot of that. There just isn't a lot of cause for someone to go referencing that file manually.

The only times I can think of someone speaking of it, it's as a black box, which we could solve by adding a command to make Fossil tell you where that file is here. Then instead of referring to ~/.fossil, you refer to $(fossil global-config) or whatever.

That said, this feels very much like someone's personal itch, not something to be imposed by popular will on volunteer developers. If someone contributes a branch for it, and it works, my only concern is that it continues to fall back to ~/.fossil for existing installs and for systems where $HOME is the correct place for such things. (e.g. The BSDs.)

The main complaint I've seen doesn't have so much to do with accessibility as it does with isolating configs so they can be moved around more easily. Which is desirable as various tools which you might want to do this with become more popular (configs checked into SCMs to be shared across machines, Docker, Nix/Guix, etc.).

As Warren noted, it's also part of a shift in FS organization on Linux, and, as more programs put their data in $XDG_*_HOME, the ones that don't begin to stick out.

And, of course, the spec is designed around (multi-)desktop integration. I, for one, use both GNOME and KDE regularly.

I personally do not use any desktop environment and do not like much of the XDG stuff. Programs should be written to work even if a desktop environment is not installed, even though some users might use it, so it shouldn't break it either.

I use Linux, and yet, I don't use XDG and desktop environment stuff. Best perhaps is to check for the XDG environment variables and if they do not exist, continue to use ~/.fossil instead. This way it will work on both Linux and on BSD.

Yeah... Someone may want to distribute Fossil as a part of some portable container (Flatpak and alike) in which case compliance with $XDG_* (and OpenDesktop in general) might save from the headaches.

Fossil could stick to ~/.fossil if it already exists, but otherwise consider a more contemporary location.

Ugh. Does this check-in appease those who hunger for XDG compliance?

(edit by Stephan: fix link to main repo, not the forum.)

This seems to be the best solution. The config location can be determined by various packaging systems rather easily, and no one needs to maintain desktop-compatibility code that they would prefer not to.

Nice. However in the case of $XDG_CONFIG_HOME, fossil.sqlite seems more reasonable to me. I don't hunger that much, though :)

Another description of the algorithm:

I think this provides XDG compatibility on new installs without breaking older installs, even on XDG-configured systems. It should just work. If you have both "fossil-new" and "fossil-old" installed on your system, they should both use ~/.fossil. If you upgrade so that only "fossil-new" is installed on your system and want to start using the XDG-named file, simply run:

    mv ~/.fossil ~/.config/fossil.db

I've seen this exact scheme used by a few projects so thumbs up.

Makes a lot of sense to me.

i'm a little late to the party here, but...

The more common convention appears, based on my systems, to be that ~/.config/XYZ are app-specific directories. My ~/.config dirs contain very few files but dozens of dirs (one per app). Perhaps using ~/.config/fossil/config.db would be the more conventional and future-proof approach, in the off chance that fossil ever gains any additional user-level files. (OTOH, we've gone 13-ish years without needing additional files, so maybe an extra level of directory is superfluous.)