My fellow software engineer, It's the year 2024...

That's what happens when you don't set $GOPATH I think

Go pisses me off with that. I separate projects the way I want but go wants every project written in go in one big directory?

Google

following industry standards

pick one

off the shelf go was too annoying for me

Nowadays I set GOENV_ROOT to an XDG location and use goenv instead.

Strange that some apps allow configuring it rather than just doing it automatically...

Thanks, I hadn't heard of that. Time to add a few hundred lines to my dotfiles :)

After running it and properly configure the paths I once again came to the conclusion: I fucking hate Google.

And i wish there was a separate XDG_LOG_HOME or $HOME/.local/log, with logrotate preconfigured to look there.

I have to use a separate Documents folder for my actual documents lol

Not to mention - this isn't necessarily the correct place for Windows anyway. That is exactly why they standardized stuff around Vista.

Plus - what about apps that store an ungodly amount data in there? Personally, I only keep the OS and basic app data (such as configs and cache) on the partition and nothing else.

Then something like Minecraft comes along and it's like "humpty dumpty I'm crapping a lumpty" and stores all its data in ".minecraft" right there in your user directory.

Then you gotta symlink stuff around and it becomes a mess...

I think that also causes issues for roaming profiles and folder redirection. If roaming is turned on then everything in the %appdata%\roaming folder is synced to a server. %AppData%\Local is not. So if your app is using %AppData%\Roaming for temporary data then you are causing a whole bunch on unnecessary IO. Same for using Documents since that if often synced.

To be fair here, appdata is technically a hidden folder and there are lots of reasons an app would want it's data accessable by the user.

I regret checking this

Whoa I’m a stickler for getting as much as I can out but even I have .zshenv and some other too hard to figure out things in there. How’d you manage a total wipeout?

This is probably a dumb question, but what program is that?

ls Volatile

I think that can be boiled down to only cd; echo .*/

Maybe throw a ;cd - on the end if the change of directory is unwanted.

ls -A | grep "^\."

I had to make a dummy .dotfile to test because I don't have hidden files in my home.

You can also just use neovim instead, among other improvements, it's configs are in the xdg dirs

XDG doesn't apply for CLI apps? About half of dirs I still have cluttering my home are GUI apps whose devs refuse to follow the specification, while I see less friction from CLI/TUI devs, since they're the ones actually seeing these hidden locations.

What makes you think XDG doesn't apply to non GUI apps?

It's not too hard to check for XDG support first and use a few hardcoded directory paths if that is unavailable.

So yes, "XDG" stands for "Cross-Desktop Group" - but I don't agree that using the spec assumes a windowing system. The base directory spec involves checking for certain environment variables for guidance on where to put files, and falling back to certain defaults if those variables are not set. It works fine on headless systems, and on systems that are not XDG-aware (I suppose that means systems that don't set the relevant env vars).

OTOH as another commenter pointed out the base directory spec can make software work when it otherwise wouldn't on a system that doesn't have a typical home directory layout or permissions.

The spec doesn't make those assumptions at all, idk where that's coming from.

I have headless machines with XDG vars configured and ones without them. XDG compliant software works in either case, but I'm less likely to use a piece of software that clutters my $HOME.

You can choose any home directory you want, as long as it's XDG_CONFIG_HOME.

Are there other relevant standards? The XDG base directory specification has been around for a long time, and is well established.

Maybe your comment wooshed over my head; if so I apologize.

Choice, huh? I can't choose where the config files are stored unless I am willing to either dig into an obscure setting, modify the source code and recompile (repeat every time there's an update), or contact the developer's smug beard using smoke signals.

For me personally I just hate that I do not know where to find configs, especially when using a dotfiles repo, it becomes harder than if they're all available under a common path.

Better organization and backup / restore. For example if you want to restore config files but don't want to move over the large ".local" folder, applications that write to $HOME will create diifculty.

Because, like /etc, you know there is a designated place for config files. It's already set for you right there, and there is a standard for it.

But what’s the difference?

I can only imagine someone asking this if they a) don't use the terminal except if Stackexchange says they should and b) have yet to try and cleanup a system that's acquired cruft over a few years. If you don't care about it, then let me flip that around and ask why you care if people use XDG? The people who care about it are the people in the spaces that concern it.

Off the top of my head this matters because:

• it's less clutter, especially if you're browsing your system from terminal
• it's a single, specified place for user specific configs, session cache, application assets, etc. Why wouldn't such important foundational things required for running apps not be in a well defined specification? Why just dump it gracelessly in the user's root folder outside of pure sloppy laziness?
• it makes uninstalling apps easier
• it makes maintenance easier
• it makes installing on new machines easier

It’ll be in /home anyways and I heard BSD had some issues with something that could be XDG.

🙄

To give one example, what if someone wants to have more than one set of options for the same app? That's something I've needed before, and it's really hard to accomplish if the app always looks in one specific place for its options.