As far as I can see, ~/.steam is just a symlink to ~/.local/share/Steam

Imho there should be an option to disable the recreation of ~/.steam.

Actually ~/.Steam seems to be a real directory for me, but it contains mostly links. Should be in ~/.config/Steam (or whatever XDG is set to: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ). There are also ~/.steampid and ~/.steampath links created all adding to home folder pollution.

It's a little sad this has received little attention. Steam still creates ~/.steampath, ~/.steampid and ~/.steam full of symlinks instead of fully using the xdg basedir spec.

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Steam still not properly implementing XDG basespecs. thanks for more shit in my home folder.

For what it's worth, I dealt with this by setting $HOME in $XDG_RUNTIME_DIR. For anyone interested in the code, here's the link.

No updates yet? How hard is to follow the XDG basespecs?

As an addendum, steam seems to partially implement it for at least the overlay since vulkan came about. However, the spec specificially...specifies...that all the XDG dirs are variables, and Steam always creates $HOME/.local/share/vulkan/implicit_layer.d/steamoverlay_{i386,x86_64}.json even if XDG_DATA_HOME is set to another location (in this case $HOME/local/data).

Since after all these years, Steam still creates no fewer than 4 garbage files in $HOME, a non-optimal workaround is to create a wrapper for steam:

#!/usr/bin/env sh
HOME=$HOME/local/data/games/steam_garbage # or wherever
exec /usr/bin/steam "$@"

This also has the beneficial side effect of fooling any rude game devs that follow Valve's example because they either don't know any better or just have a philosophical appreciation for slovenliness.

this sucks. please fix this, I dont want any of this garbage in my home folder

The steam Linux client is in dire need of many QOL fixes, this being a big one.

Hi, I'm sure another bump here won't do much but I'll go ahead and do it anyway and see if maybe I can poke some of my valve contacts to take a look at this.
Please fix this, this is extremely low hanging fruit that leaves a bad taste in people's mouths when trying out steam on Linux. I use my laptop running Fedora for work, and it seriously does not help to have my home directory littered with various save files for games simply because you guys didn't take the time to do what literally almost everything else on Linux has been doing for years.

If these files are needed for older games. Why not just create them when you install the old game?
Instead of putting broken symlinks in my home directory.

I have been waiting this feature for years. I'm really grateful for what steam has done for linux gaming and nobody can deny that. But steam you also have to look at what people are requesting out here and should try to follow the linux way instead of other way around. I'm hopeful that after this crisis is over you would give a serious consideration for following the standard XDG_BASE_DIRECTORY

Just piling on here to point out this still hasn't been changed. Emacs is something like 40 years old, and their next release will support XDG Base Directory configuration. Valve can do this.

come on....... follow specs

It's bad enough when a program create 1 dotfile/directory in $HOME, but three? And two of them are symlinks? Follow specs.

Yeah, its funny how valve created proton so that almost any windows game runs flawless in linux.
But a simple script that creates some symlinks when you start the few old games that require it, is not on their todo list.
You could even make it so that when the game launches the symlinks are created, and when you quit te game, the symlinks are removed...

This issue was opened in 2013. 7 years have passed and Steam is still cluttering our ~/home with .steam directory instead of following XDG standard. :(

I thank Valve for all the effort they put into making things work on Linux.
At least if they cannot follow the spec perfectly I would prefer them not put anything under $HOME, putting everything under $XDG_DATA_HOME/Steam would be a fine start.

Come on, this is an easy issue to fix. Can't take 7 years to address.

Bump. Joining people above

Bump. I hope Valve will solve this issue sooner.

Here's an improved version of @escondida's script:

#!/usr/bin/env sh

OLDHOME=$HOME
HOME=$XDG_DATA_HOME/Steam/fakehome # Replace this with where you want it to be

# Replaces every / of the first argument with \/
replace_slash() {
	echo $1 | sed "s/\//\\\\\//g"
}

# Symlink a file to the fake home
link_dir() {
	# Replace OLDHOME with HOME in the link name
	link_name=$(echo $1 | sed "s/^$(replace_slash $OLDHOME)/$(replace_slash $HOME)/")

	# Creates the link's parent directory and symlinks it
	mkdir -p $(dirname $link_name)
	[ ! -d $link_name ] && ln -s $1 $link_name
}

mkdir -p $HOME

link_dir $XDG_DATA_HOME   # ~/.local/share
link_dir $XDG_CACHE_HOME	 # ~/.cache
link_dir $XDG_CONFIG_HOME # ~/.config
link_dir $OLDHOME/.icons  # ~/.icons (lxappearance's mouse cursor theme)

# If .steam exists in ~/ and not in the fake home, move it to the fake home
[ -d $OLDHOME/.steam ] && [ ! -d $HOME/.steam ] && mv $OLDHOME/.steam $HOME/

exec /usr/bin/steam "$@"

I have only tested it in Arch Linux and with a few games (CS:GO and Factorio at the moment). They both work but factorio still uses ~/.factorio even if you change the launch options inside of steam to point $HOME to somewhere else.

Also, Valve please fix.

Day 2918

Yet another bump, a prayer at this shrine
I doubt valve will hear any cries of mine
Seven years I count, and eight to come
A specification so simple, yet never done

This issue was opened in 2013, and yet 8 years (3008 days) down the line it is still an issue.

bump. the funniest thing among all this is that ~/.steampath doesn't even point to any valid path. it goes to ~/.steam/sdk32/steam which doesn't exist

Bump again.

bump, my home directory is already a huge mess and steam is just immovable

You can install Steam in Flatpak to tidy your system up a bit, but at the moment it breaks pressure-vessel (if you don't apply a patch).

You can install Steam in Flatpak to tidy your system up a bit, but at the moment it breaks pressure-vessel (if you don't apply a patch).

Flatpak is also not XDG Base Directory Spec. compliant.

@Neurognostic

You can install Steam in Flatpak to tidy your system up a bit, but at the moment it breaks pressure-vessel (if you don't apply a patch).

Flatpak is also not XDG Base Directory Spec. compliant.

More compliant and definitely neater than just bare Steam.

The best solution I have found so far is to give Steam it's own user and home directory. It does not address this issue but does clean up your own home directory without using crap like Flatpak.

@livmackintosh Details? =)

I don't create a separate user, I just change the HOME variable when I launch steam.

#!/bin/sh

HOME="/home/mou/tmp/homes/steam"
[ -d ${HOME} ] || mkdir -p "${HOME}"

exec /usr/bin/steam "$@"

of course change the variable to fit your needs.

Here's an improved version of @escondida's script:

#!/usr/bin/env sh
# stripped away for brevity

I have only tested it in Arch Linux and with a few games (CS:GO and Factorio at the moment). They both work but factorio still uses ~/.factorio even if you change the launch options inside of steam to point $HOME to somewhere else.

Also, Valve please fix.

While I love this solution by @mateusauler , it didn't work out of the box because of some trailing slashes in my XDG paths... so I cleaned it up a bit. I think I went overboard, but:

#!/usr/bin/env sh

REALHOME=$HOME
FAKEHOME=/opt/games/steam # Replace this with where you want it to be

# Adds symlinks for actual paths in fakehome
remember() {
	# Replace OLDHOME with HOME in the link name
	fake_dir=$(echo $1 | sed "s:^$REALHOME:$FAKEHOME:")
	echo -en "Relinking '$1' to '$fake_dir'... "

	# Creates the link's parent directory and symlinks it
	mkdir -p $(dirname $fake_dir) || echo "Failed to create parent dirs"
	ln -s "$1" -t "$(dirname ${fake_dir})" 2> /dev/null
	ret=$?
	[ "$ret" -eq "0" -o "$ret" -eq "1" ] && return 0 || return 1
}
forget() {
	fake_dir=$(echo $1 | sed "s:^$REALHOME:$FAKEHOME:" | sed 's:^\(.*\)/$:\1:')
	echo -en "Unlinking '$fake_dir'... "
	unlink "$fake_dir" 2> /dev/null
	ret=$?
	[ "$ret" -eq "0" -o "$ret" -eq "1" ] && return 0 || return 1
}

try() {
	$@
	ret=$?
	[ "$ret" -eq "0" ] && echo "Ok" || echo "Failed" 
	[ "$ret" -eq "0" ] || export error=1
}

paths() {
	try $1 ${XDG_DATA_HOME:-$REALHOME/.local/share}
	try $1 ${XDG_CACHE_HOME:-$REALHOME/.cache}
	try $1 ${XDG_CONFIG_HOME:-$REALHOME/.config}
	try $1 ${REALHOME}/.icons # ~/.icons (lxappearance's mouse cursor theme)
}
move_steam() {
	# If .steam exists in ~/ and not in the fake home, move it to the fake home
	should_move_steam=0
	[ -d $OLDHOME/.steam ] && [ ! -d $FAKEHOME/.steam ] && should_move_steam=1 || return 0
	[ "$should_move_steam" -eq "1" ] && mv $OLDHOME/.steam $HOME/ && return 0

}
main() {
	export HOME=${FAKEHOME}
	mkdir -p $FAKEHOME

	error=0
	paths remember || error=1
	move_steam || error=1

	[ "$error" = "0" ] && exec /usr/bin/steam "$@" || echo "Failed to fakehome steam"
}

main

You can remove the symlinks with paths remove. I use the same $FAKEHOME as where I find my steamapps folder. I also noticed .pki/, .pulse-cookie, and .dbus/ appear in the directoy on launching steam, together with .steampath and .steampid. Should we add symlinks to those too?

As a small note, I saved this fileas /usr/loca/bin/steam, since it makes sense by the FHS.

I did a regex through all the files under $XDG_DATA_HOME/steam/ (thanks ripgrep) for anything trying to do ln -s ** and immediately found some telling things in $XDG_DATA_HOME/steam/steam.sh

# We use ${HOME%/}/.steam for bootstrap symlinks so that we can easily
# tell partners where to go to find the Steam libraries and data.
# This is constant so that legacy applications can always find us in the future.
STEAMCONFIG="${HOME%/}/.steam" # Drop tailing slash in home folder if it exists.
PIDFILE="$STEAMCONFIG/steam.pid" # pid of running steam for this user
STEAMBIN32LINK="$STEAMCONFIG/bin32"
...

These vars are implemented as symlinks with this code:

	# Create symbolic links for the Steam API
	if [ ! -e "$STEAMCONFIG" ]; then
		mkdir "$STEAMCONFIG"
	fi
	if [ "$STEAMROOT" != "$STEAMROOTLINK" -a "$STEAMROOT" != "$STEAMDATALINK" ]; then
		rm -f "$STEAMBIN32LINK" && ln -s "$STEAMROOT/$PLATFORM32" "$STEAMBIN32LINK"
		rm -f "$STEAMBIN64LINK" && ln -s "$STEAMROOT/$PLATFORM64" "$STEAMBIN64LINK"
		...
		if [ "$STEAMDATALINK" ]; then
			rm -f "$STEAMDATALINK" && ln -s "$STEAMDATA" "$STEAMDATALINK"
		fi
	fi

	# Temporary bandaid until everyone has the new libsteam_api.so
	rm -f ~/.steampath && ln -s "$STEAMCONFIG/sdk32/steam" ~/.steampath
	rm -f ~/.steampid && ln -s "$PIDFILE" ~/.steampid
	rm -f ~/.steam/bin && ln -s "$STEAMBIN32LINK" ~/.steam/bin
	# Uncomment this line when you want to remove the bandaid
	# rm -f ~/.steampath ~/.steampid ~/.steam/bin

It would be ugly to paste any more of the relevant code; but more context makes it look like the $STEAMCONFIG var defines most, and likely all, of the home-folder files places in $HOME/.steam. I can't speak for the files placed in the home-folder outside ~/.steam, as mentioned by @mazunki, but simply changing STEAMCONFIG="${HOME%/}/.steam" to STEAMCONFIG="${XDG_CONFIG_DIR:-"$HOME/.config"}/steam" might be a trivial change which would alleviate at least part of the XDG issue. Importantly, given that these symlinks are re-generated each time steam is launched, there is no need to worry about backwards compatibility with older paths.

As mentioned by @mazunki, I also get some of those stray files (all of them except .dbus/). .pki being in the home-folder has been fixed in upstream NSS/WebKit, chromium, or whatever relevant web-engine is used; so I think the issue there might be some component of the steam runtime and/or it's web-ui(s). .pulse-cookie is a similar case; it has been fixed in upstream pulse (see 59a8618 and 87ae830)

As a final note, I really do hope that a maintainer or really anyone more familiar with the relevant code would be kind enough to offer some information on what can be done to eventually get a fully-functional PR up. If the code relevant to this issue is all just in the bash scripts, then I would be more than willing to get to work on it ASAP.

EDIT: Nearly the exact same issues exist in the executable linked to at /usr/bin/steam (/usr/lib/steam/bin_steam.sh). It's maybe slightly worse because it refers to home with "~" and not "$HOME".

As an addendum, steam seems to partially implement it for at least the overlay since vulkan came about. However, the spec specificially...specifies...that all the XDG dirs are variables, and Steam always creates $HOME/.local/share/vulkan/implicit_layer.d/steamoverlay_{i386,x86_64}.json even if XDG_DATA_HOME is set to another location (in this case $HOME/local/data).

Posted 2016, now it's almost 2022, and besides all of the ~/.steam* folders and symlinks it still entirely ignores $XDG_DATA_HOME and just creates ~/.local/share/vulkan/implicit_layer.d/ when the client is launched, every single time. Besides the crazy hacks posted on this thread, some package repositories go as far as to include a wrapper to containerise Steam to control the up to 5 new things it makes in your home directory. This issue is about to turn 9 years old. Valve, please cooperate.

EDIT: This is also ignored for ~/.local/share/applications, where desktop icons are installed.

I might be wrong but isn't the vulkan one due to the dependency not supporting XDG dirs? It seems to only look for the dirs listed here: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/LoaderAndLayerInterface.md#linux-layer-discovery

EDIT: actually that was an old repo. Looks like it does support it https://github.com/KhronosGroup/Vulkan-Loader/issues/245

2022 bump

Here's hoping they eventually notice these bumps that everyone is doing, but fwiw i'd agree with the request/fix proposed here

+1 9 years. Just why?

I know that many consider it poor form to "+1 comment" and necrobump longstanding issues wherein all of the merits, tradeoffs, and solutions have already been beaten to death, but personally I think that if it continues to annoy enough people for long enough, a quiet :+1: on the parent comment does not provide the necessary amount of satisfaction and camaraderie we get from being reminded of our shared suffering.

There should be a leaderboard for high-profile software projects that still can't figure out how to not barf data randomly all over your filesystem.

Honestly it's kind of funny that every week or so I get a couple E-mails just for people bumping this thread.

I know that many consider it poor form to "+1 comment" and necrobump longstanding issues wherein all of the merits, tradeoffs, and solutions have already been beaten to death, but personally I think that if it continues to annoy enough people for long enough, a quiet +1 on the parent comment does not provide the necessary amount of satisfaction and camaraderie we get from being reminded of our shared suffering.

There should be a leaderboard for high-profile software projects that still can't figure out how to not barf data randomly all over your filesystem.

The leaderboard is on the Arch Linux wiki. Would be kinda funny to add a date column there.

Valve try to fix the most basic thing ever challenge (impossible)

Bash and Steam, barfing up my home directory

@frankc-valve Is there perhaps any update on this? ...Or maybe someone relevant to this type of feature that could be notified & asked for any answer?

Unfortunately, I'm not sure who to > - [@ping] about this myself, and there's no 'discussion' tab enabled for this repo either that I could post to. :/

Like if it breaks things and the commits proposed in the threads mentioned here can be added to an existing pull-request then could it not be a simple fix?

Or would we be permitted to have a pull request accepted from ourselves as users? (unsure if a CLA would need to be signed or anything else with it)

Or would we be permitted to have a pull request accepted from ourselves as users? (unsure if a CLA would need to be signed or anything else with it)

Since this repo contains no source code, that unfortunately isn't possible.

Or would we be permitted to have a pull request accepted from ourselves as users? 👀 (unsure if a CLA would need to be signed or anything else with it)

Since this repo contains no source code, that unfortunately isn't possible.

Well in that case I wonder if Steam could be "Source-Available"©️ instead? With no license file & A simple "©️ All Rights Reserved" quote at the start of the ReadMe.md file. Although I bet they'd be even more opposed than in the currently proposed changes, even if nobody else has any other right but to see & suggest code.

Well in that case I wonder if Steam could be "Source-Available"©️ instead?

You think they'll straight up ignore this issue for almost 10 years now but make the client source-available?

Well in that case I wonder if Steam could be "Source-Available"©️ instead?

You think they'll straight up ignore this issue for almost 10 years now but make the client source-available?

I have faith that it'll be considered, surely they wouldn't ignore this issue. Right?

Day 3368

A drop or two and follows a river of tears
How the cries of the anguished fall on deaf ears
A $HOME I believed I'm the one to own
Excalibur lifted and this issue remains in stone

Well in that case I wonder if Steam could be "Source-Available"©️ instead?

You think they'll straight up ignore this issue for almost 10 years now but make the client source-available?

I have faith that it'll be considered, surely they wouldn't ignore this issue. Right?

Okay on second thoughts nvm, are we sure they haven't just left Github now instead staying for the issues/bug reports?

coming here after using xdg-ninja ; sure is a goldmine

COME ON, VALVE

FOLLLOW XDG Base Directory Specification

WE LOVE YOU AND WILL LOVE YOU EVEN MORE FOR THIS

Damn you Valve for pushing Arch Linux but can't even follow the damn spec, least give us some damn environment variables instead of HARDCODED VARIABLES TO OUR DAMN HOME DIRECTORY!!! I don't even care if games ignore it, the least you could do is read the environment variables so even if you ignore the defaults we can modify our env to make it compliant.

ITS NOT THAT DAMN HARD!!!!

As an aside third party tools shouldn't be expected to operate outside of launching from Steam so if they really won't correct it and the steam API isn't being called to find anything regarding ~/.steam, then when steam launches a game it should symlink for ~/.steam to wherever the steam directory is and then destroy that afterwards, (generally no one will care about the pollution in $HOME if they're playing a game or using a tool, its the best workaround Steam could implement) or in the least allow us to define that ourselves without redefining $HOME as that's a very bad workaround

it seems our suffering will never get noticed by valve..

No, don't be mistaken, they do notice it: https://github.com/ValveSoftware/steam-for-linux/issues/8634#issuecomment-1158156504. They just don't care.

it seems our suffering will never end..**

Steam devs, i love you, but this is to much

Damn you Valve for pushing Arch Linux but can't even follow the damn spec, least give us some damn environment variables instead of HARDCODED VARIABLES TO OUR DAMN HOME DIRECTORY!!! I don't even care if games ignore it, the least you could do is read the environment variables so even if you ignore the defaults we can modify our env to make it compliant.

ITS NOT THAT DAMN HARD!!!!

As an aside third party tools shouldn't be expected to operate outside of launching from Steam so if they really won't correct it and the steam API isn't being called to find anything regarding ~/.steam, then when steam launches a game it should symlink for ~/.steam to wherever the steam directory is and then destroy that afterwards, (generally no one will care about the pollution in $HOME if they're playing a game or using a tool, its the best workaround Steam could implement) or in the least allow us to define that ourselves without redefining $HOME as that's a very bad workaround

At this point, I'll be happy if they just remove the ~/.steam directory and just keep everything in ~/.local/share/Steam like they are currently doing.

Maybe after that they could do a more fine grained splitting.

💀

Greetings from 2022 time traveller, we hope this is closed in your future.

Just uninstalled Steam from my machine after installing for a brief moment as I saw the amount of files it created in my home directory. That's pretty bad.

I leave on record my support for the change to respect the default directories (XDG Base DIrectory Specification). Please Valve.

Edit: XGB to XDG, correcting misspelling.

"(XGB Base DIrectory Specification)."

Pretty sure you're meaning "XDG" here… Totally agree though that it would be super-nice if Valve went ahead and put their files inside $HOME/.local/valve/steam or somesuch similar (and maybe made use of $HOME/.config and $HOME/.cache appropriately if they feel like it, too…) per those XDG Base Directory standards like so very many other software developers have chosen to. You'd think this would have already long since been done, seeing as how long Valve's been using and supporting Linux now.

.steam is just a bunch of symlinks :joy:

This has been open for 9 years, 5 months, and 19 days so far …

9 years, 5 months, 15 days...... as of today (Tuesday, 2 August 2022)......

I'd imagine us celebrating 10 years

Are they just unable to see this?
I think they moved their stuff to Gitlab after shifting the SteamOS stuff on there

They're hiding comments they deem not too constructive, so no, they're definitely seeing it.

They're hiding comments they deem not too constructive, so no, they're definitely seeing it.

I believe that would be the moderator

Steam HQ

Planning a party when this thread turns 10 years, let me know if anyone wants an invite

Any ideas on what we could do to bring more attention to this? It should be a quick and easy fix surely, and it would be much appreciated to reduce clutter in the home directory.

Yeah this isn't even the right place to be asking this

if steam actually had its code open source, this is easier done than said

Yeah this isn't even the right place to be asking this

What would be the right place, Steam Forums?

Yeah this isn't even the right place to be asking this

There is no better place to be asking about this. You'd think after almost 10 years that would have been cleared up, yet this issue remains open

Planning a party when this thread turns 10 years, let me know if anyone wants an invite

I assume that reacting with a party emoji means I'm signed up, right?

if steam actually had its code open source, this is easier done than said

You can't expect a megacorporation to do so. Some will opensource their libraries/tooling/programming languages/etc.; most do, in fact. Google and Microsoft are great examples of that. C#, .Net Core, Kubernetes, Go, Flutter, Dart, VSCode... The list goes on. But notice how their server and client code is rarely FOSS. So it's rather unreasonable to expect Valve to make the Steam client FOSS. Would I want it? Hell yea! But I'm not expecting that to happen, ever.

What's more likely is that someone will just PR it into SteamOS 3.0 once sources for that are released (which they have to do, otherwise FSF could sue them) via some hacky way that completely goes around Steam's proprietary binary, Valve sees that and goes „Oh, wow, maybe we should make it a proper part of the OS instead of a weird hack” and implements it as a feature of not just SteamOS but (fingers crossed!) the base Steam Client as well. Or... The PR just gets rejected, which is the more likely option.

Any ideas on what we could do to bring more attention to this? It should be a quick and easy fix surely, and it would be much appreciated to reduce clutter in the home directory.

Would probably be to reach out to someone working on it, or someone who could get the right people onboard to have something done about it atleast.
I forget the name, began with P and worked on gamescope renderer? 🤔 (Although that's probably of no help by itself with how much I've forgotten)

It still beats all of us just @'ing Valve/Steam Support on Twitter though, right? Unless you guys have tried it and actually got some help with that 😅

Valve clearly don't use this anymore with the only people in the GitHub rn are the mods, and I think even they have just left us to it at this point...

if steam actually had its code open source, this is easier done than said

You can't expect a megacorporation to do so. Some will opensource their libraries/tooling/programming languages/etc.; most do, in fact. Google and Microsoft are great examples of that. C#, .Net Core, Kubernetes, Go, Flutter, Dart, VSCode... The list goes on. But notice how their server and client code is rarely FOSS. So it's rather unreasonable to expect Valve to make the Steam client FOSS. Would I want it? Hell yea! But I'm not expecting that to happen, ever.

What's more likely is that someone will just PR it into SteamOS 3.0 once sources for that are released (which they have to do, otherwise FSF could sue them) via some hacky way that completely goes around Steam's proprietary binary, Valve sees that and goes „Oh, wow, maybe we should make it a proper part of the OS instead of a weird hack” and implements it as a feature of not just SteamOS but (fingers crossed!) the base Steam Client as well. Or... The PR just gets rejected, which is the more likely option.

Speaking of which, where is that source code? It's been quite a while... 🤔

I occasionally found the issue from xdg-ninja, and it's surely a goldmine.

Day 3589
Valve, the mighty giant, seated on its throne
But the users below, we are left alone
Free from dot files, from chaos and strife
Valve, it's time to end this nine year life.

Maybe we will get it soon for our 10th anniversary of this issue.

Maybe we will get it soon for our 10th anniversary of this issue.

That actually feels like a very Valve thing to do...

First post of 2023! This is still very much a thing that needs to be addressed. Us who care about the tidyness of their home directory would still like steam to put those unnecessary files where they belong: paths specified by XDG.

Has anyone made a list of which directories SHOULD be in some specific XDG-Spec directory?
If so we might do it manually by moving the contents of those directories to the proper places and just put symbolic-links in the spots Steam uses until they fix it them self...

I might be able to make a script that performs those actions automatically if i have that info...

we might do it manually by moving the contents of those directories to the proper places and just put symbolic-links in the spots Steam uses until they fix it them self...

One of the main reasons for following the XDG Base Directory spec is to clear out the garbage from your home directory. There is practically no difference between garbage files/directories and garbage symlinks, so what's the point?

so what's the point?

It could be space related, if those directories are on other file-systems...
But yea if they are on same as your ~/, then it won't matter where they are stored under ~/, not even if the sub-dir is different :wink:

valve plz fix

There is practically no difference between garbage files/directories and garbage symlinks, so what's the point?

One thing that just came to my mind is that maybe one could make a script that automatically links it upon Steam's startup, and unlinks when it's no longer running. This way - one will only have spam in HOME when the client is in active use. That's actually what I meant by

some hacky way that completely goes around Steam's proprietary binary

in one of my previous posts in this thread.

idk if that was said but flatpak steam doesnt need/create ~/.steam

Edit: lets spin up a discord server/matrix room to celebrate 10th anniversary

idk if that was said but flatpak steam doesnt need/create ~/.steam

it does, it's just contained in ~/.var, which is similarly hardcoded lol

We'll probably be all dead until Steam decides to give some attention to this XDG issue and mostly Linux users.

Come on, it's an easy fix and standards exist for a reason. Follow those XDG paths.

to the valve employee marking all these comments as offtopic consider people are trying to bring attention to this issue because it's been actively ignored for a decade!! i am confident that the users would be more than satisfied if they could get an update of any kind whatsoever after all this time instead of just shouting into the void hoping for answers that might never come

At this point it probably took them longer to mark comments as off-topic than it would've taken to just implement the feature...

Since after all these years, Steam still creates no fewer than 4 garbage files in $HOME, a non-optimal workaround is to create a wrapper for steam:

#!/usr/bin/env sh
HOME=$HOME/local/data/games/steam_garbage # or wherever
exec /usr/bin/steam "$@"

This also has the beneficial side effect of fooling any rude game devs that follow Valve's example because they either don't know any better or just have a philosophical appreciation for slovenliness.

Reminder to everyone who may be annoyed by this issue that this fix is currently still the most efficient method of getting around having extra dotfiles litter your home directory. If you run steam from a menu launcher like rofi or dmenu you can edit steam's .desktop file in /usr/share/applications/ and change the Exec line to point to the wrapper script with Exec=/home/yourname/scripts/steam_wrapper.sh, obviously changing the path to the location of the script. That way your menu will run steam through the wrapper rather than creating new dotfiles.

What's the difference between exec and just launching Steam from its native command?

What's the difference between exec and just launching Steam from its native command?

exec would replace the shell process interpreting the script with the following command, which is quite useful to do at the end of a shim, as it cleans up the shell process in advance, and also makes it so that the return code of steam is also the return code of the wrapper. see
the linux manual page on execve(2) or read posix to get a better idea about unix fundamentals

still waiting

Not that it'll matter, but I'll also voice my support on this. I'll be implementing the wrapper script that's been suggested on my end. I'd also accept an official Flatpak solution to move this junk into a sandbox that won't affect legacy games that rely on it (assuming they'd also run in the Steam sandbox).

@Zsargul and what about creating a bubblewrap sandbox to deal with it?
I think it would be cleaner and would allow for a more fine grained control about where does steam place it's crap.

I'm also implementing it on some games that like to create a dir in my home folder.

Still waiting for valve to come and fix this, please. They even have a linux handheld pc now.

any updates ??

They really should close this issue if they don't want to consider it. We may as well give up, Not sure if they've even seen this.

Using proper paths would also allow actual packages (i.e. not bootstrappers) to exist.

The temptation to just patch the binary is strong, but I'm pretty sure it's against the license...

Steam as it stands is just a nightmare for users and distribution maintainers.

The temptation to just patch the binary is strong, but I'm pretty sure it's against the license...

I'm sure that is aginst the terms of their EULA and would also require reverse engineering the binary... I would try the sandbox approach and post any progress.

And yeah, steam is a nightmare. It still is a 32bit app...

The temptation to just patch the binary is strong, but I'm pretty sure it's against the license...

LD_PRELOAD still exists, one could shim filesystem calls, doubt they use the syscalls to do so, probably just libc and/or libc++

Steam as it stands is just a nightmare for users and distribution maintainers.

Especially considering only .deb is provided (related: #7267) which is a complete joke and everyone has to work around it. SteamOS isn't even debian based anymore

Especially considering only .deb is provided (related: #7267) which is a complete joke and everyone has to work around it. SteamOS isn't even debian based anymore

Exactly, in fact in OpenMandriva we just extract the tarball when building the RPM archive: https://github.com/OpenMandrivaAssociation/steam

LD_PRELOAD still exists, one could shim filesystem calls, doubt they use the syscalls to do so, probably just libc and/or libc++

Excellent idea! We should be able to simply log the calls with strace and then write an interceptor that rewrites the paths.

Alright, I quickly wrote a library implementing an fopen() logger and it works as expected, for both 32 bit (e.g. steam) and 64 bit (e.g. steamwebhelper) processes.

The idea is to install it system-wide, for both architectures. If the directories are correct, you can just do LD_PRELOAD=libsteam_xdg_enforcer.so steam and ld will take care of loading the correct binary depending on the process you're injecting it into.

I'll pour some time into this and create a repository soon.

Change of plans: let's rely on FUSE to achieve what we need. The LD_PRELOAD idea is way too fragile for my taste and a virtual filesystem is probably the right tool for the job anyway.

I have already written most of the code, now it's pretty much just a matter of implementing the redirection based on the target (e.g. steam.pid should go in /var/run/user/<uid>).

Running the program: steam_xdg_enforcer ~/.steam

should go in /var/run/user/...

this shouldn't be enforced, please use the XDG_RUNTIME_DIR variable instead, and error out if it doesn't exist.

Yes, absolutely. Also, the idea is to make all paths configurable through environment variables.

Ready for testing!

https://github.com/OpenMandrivaSoftware/steam_xdg_enforcer

@davidebeatrici why not make it as simple as LD_LIBRARY_PATH and not depend on external variables? That means it doesn't really support XDG, and is optional. It should be enforced via preprocessor hardcoded C variables.

I can implement default values, no problem. Feel free to open an issue.

Change of plans: let's rely on FUSE to achieve what we need. The LD_PRELOAD idea is way too fragile for my taste and a virtual filesystem is probably the right tool for the job anyway.

I have already written most of the code, now it's pretty much just a matter of implementing the redirection based on the target (e.g. steam.pid should go in /var/run/user/<uid>).

Running the program: steam_xdg_enforcer ~/.steam

@davidebeatrici I honestly don't understand, what's the point of using FUSE here. Your solution still creates a .steam directory in the user's home.

This doesn't solve the problem for people who don't like clutter in their home. This doesn't work for people, who have a read-only home directory. So what's the point?

What's the difference between your solution and just installing a symlink (or a bind mount) from ~/.steam to the desired location?

.steam is the only directory that must exist, as it's hardcoded in the steam binary and other places.

I agree that ideally we should get rid of it as well, but that's entirely up to @ValveSoftware.

My solution works for people who have a read-only home directory, as the .steam folder is actually always empty. The program maps all entries through FUSE.

The biggest difference between a plain symlink and a virtual filesystem is that with the latter we can intercept all calls within the mount point, allowing us to have a system-wide read-only Steam installation (and in turn a proper distribution package, with updates and everything).

See the current mapping table: https://github.com/OpenMandrivaSoftware/steam_xdg_enforcer/blob/d41dd98579ec3d907f55563a4ec55b4afe5659e2/path.c#L96-L113

...but your solution still makes the directory exist. Steam uses ~/.local/share/Steam too in some cases.

My solution works for people who have a read-only home directory, as the .steam folder is actually always empty.

Yeah, but you still need to create the directory.

The biggest difference between a plain symlink and a virtual filesystem is that with the latter we can intercept all calls within the mount point, allowing us to have a system-wide read-only Steam installation (and in turn a proper distribution package, with updates and everything).

I'm gonna be honest here, I don't really understand what does the system-wide steam installation have to do with the per-user ~/.steam directory.

Either way, it doesn't sound to me like your solution addresses the problem described in this issue - namely the fact that Steam doesn't follow the XDG Base Directory Specification.

...but your solution still makes the directory exist. Steam uses ~/.local/share/Steam too in some cases.

The bootstrapper simply creates a symlink:

lrwxrwxrwx 1 user user  23 Apr 22 01:02 bin -> /home/user/.steam/bin32
lrwxrwxrwx 1 user user  41 Apr 22 01:02 bin32 -> /home/user/.local/share/Steam/ubuntu12_32
lrwxrwxrwx 1 user user  41 Apr 22 01:02 bin64 -> /home/user/.local/share/Steam/ubuntu12_64
-rwxrwxr-x 1 user user 305 Apr 22 01:03 registry.vdf
lrwxrwxrwx 1 user user  29 Apr 22 01:02 root -> /home/user/.local/share/Steam
lrwxrwxrwx 1 user user  37 Apr 22 01:02 sdk32 -> /home/user/.local/share/Steam/linux32
lrwxrwxrwx 1 user user  37 Apr 22 01:02 sdk64 -> /home/user/.local/share/Steam/linux64
lrwxrwxrwx 1 user user  29 Apr 22 01:02 steam -> /home/user/.local/share/Steam
-rw-rw-r-- 1 user user   6 Apr 22 01:02 steam.pid
prw------- 1 user user   0 Apr 22 01:01 steam.pipe
-r-------- 1 user user  16 Apr 22 01:02 steam.token

Yeah, but you still need to create the directory.

You can do it before making your home directory read-only.

I'm gonna be honest here, I don't really understand what does the system-wide steam installation have to do with the per-user ~/.steam directory.

Steam as it stands can be installed system-wide by simply making symlink, but you have to give write permissions to the user it runs as (potential security issue).

Either way, it doesn't sound to me like your solution addresses the problem described in this issue - namely the fact that Steam doesn't follow the XDG Base Directory Specification.

Have you read my program's mapping code? It takes care of redirecting filesystem calls based on the path that is accessed.

For example, steamapps is considered to be writable and user-specific, thus it adheres to STEAM_DATA_DIR.

On my test VM this is the result:

$ ls -l ~/.steam
total 0
lrwxrwxrwx 1 root root   5 Jan  1  1970 bin -> bin32
lrwxrwxrwx 1 root root  16 Jan  1  1970 bin32 -> root/ubuntu12_32
lrwxrwxrwx 1 root root  16 Jan  1  1970 bin64 -> root/ubuntu12_64
drwxr-xr-x 1 root root 792 Apr 23 03:24 root
lrwxrwxrwx 1 root root  12 Jan  1  1970 sdk32 -> root/linux32
lrwxrwxrwx 1 root root  12 Jan  1  1970 sdk64 -> root/linux64
lrwxrwxrwx 1 root root   4 Jan  1  1970 steam -> root

root actually points to /usr/libexec/steam.

$ ls -l ~/.steam/root
total 45832
drwxrwxr-x 1 root root       70 Apr 22 01:02 bin
-rwxrwxr-x 1 root root    11384 Feb 11  2014 bin_steamdeps.py
-rw-r--r-- 1 root root  3677776 Apr 22 01:00 bootstrap.tar.xz
drwxrwxr-x 1 root root      100 Apr 22 01:02 clientui
drwxrwxr-x 1 root root     1398 Apr 22 01:02 controller_base
-rwxrwxr-x 1 root root      718 Nov 18 21:19 fossilize_engine_filters.json
drwxrwxr-x 1 root root     5526 Apr 22 01:02 friends
-rwxrwxr-x 1 root root  1415528 Mar 24 19:24 GameOverlayRenderer64.dll
drwxrwxr-x 1 root root    26388 Apr 22 01:02 graphics
drwxrwxr-x 1 root root      204 Apr 22 01:02 legacycompat
drwxr-xr-x 1 root root       94 Apr 22 01:02 linux32
drwxrwxr-x 1 root root       58 Apr 22 01:02 linux64
drwxrwxr-x 1 root root     4394 Apr 22 01:02 package
drwxrwxr-x 1 root root     7518 Apr 22 01:02 public
drwxrwxr-x 1 root root    11054 Apr 22 01:02 resource
drwxrwxr-x 1 root root     2358 Apr 22 01:02 servers
drwxrwxr-x 1 root root       22 Apr 22 01:02 steam
-rwxrwxr-x 1 root root 22417616 Mar 24 19:24 steamclient64.dll
-rwxrwxr-x 1 root root 19072872 Mar 24 19:24 steamclient.dll
-rwxrwxr-x 1 root root      857 Oct  8  2013 steamdeps.txt
-rwxrwxr-x 1 root root     1316 Jul 10  2019 steam_msg.sh
-rwxrwxr-x 1 root root    23057 Jan  2 18:02 steam.sh
-rwxrwxr-x 1 root root    49827 Jun  1  2018 steam_subscriber_agreement.txt
drwxrwxr-x 1 root root      316 Apr 22 01:02 steamui
drwxrwxr-x 1 root root       16 Apr 22 01:02 tenfoot
-rwxrwxr-x 1 root root      405 Dec 24  2013 ThirdPartyLegalNotices.css
-rwxrwxr-x 1 root root    25088 Dec 17  2013 ThirdPartyLegalNotices.doc
-rwxrwxr-x 1 root root   202978 May  6  2019 ThirdPartyLegalNotices.html
drwxr-xr-x 1 root root     2006 Apr 22 01:02 ubuntu12_32
drwxrwxr-x 1 root root     1612 Apr 22 01:02 ubuntu12_64

$ ls -l ~/.steam/root/steamapps
total 12
-rwxrwxr-x 1 user user  763 Apr 26 06:47 appmanifest_40.acf
-rwxrwxr-x 1 user user 1015 Apr 26 07:16 appmanifest_70.acf
drwxrwxr-x 1 user user   18 Apr 25 04:21 common
drwxrwxr-x 1 user user    0 Apr 26 06:47 downloading
-rwxrwxr-x 1 user user  274 Apr 26 07:57 libraryfolders.vdf
drwxrwxr-x 1 user user    4 Apr 25 04:23 shadercache
drwxrwxr-x 1 user user    0 Apr 25 04:20 sourcemods
drwxrwxr-x 1 user user    0 Apr 26 06:47 temp

I'm gonna be honest here, I don't really understand what does the system-wide steam installation have to do with the per-user ~/.steam directory.

Steam as it stands can be installed system-wide by simply making symlink, but you have to give write permissions to the user it runs as (potential security issue).

Are you perhaps suggesting that current package managers don't "install steam system-wide", because the (globally installed) steam executable "manually" downloads libraries and updates and stuff into each users' directory instead of making the system package manager download those?

If that's what you are really trying to achieve, then I can only wish you good luck. IMHO, trying to fight with an application that wants to manage its own updates is a loosing battle (unless the application author actually wants to support such a use case, which Valve clearly doesn't).

Either way, it doesn't sound to me like your solution addresses the problem described in this issue - namely the fact that Steam doesn't follow the XDG Base Directory Specification.

Have you read my program's mapping code? It takes care of redirecting filesystem calls based on the path that is accessed.

For example, steamapps is considered to be writable and user-specific, thus it adheres to STEAM_DATA_DIR.

The XDG Base Directory Specification (informally) tells you to "put files into their respective base directories instead of stuffing them all into $HOME/.shittyapp". The FUSE shim that you are proposing doesn't remove ~/.steam from your home dir. Your shim (might) solve the "organize files into their respective base directories" part, but it doesn't address the fact that Steam is still expecting to find a .steam directory in your home.

$ ls -l ~/.steam/root
total 45832
drwxrwxr-x 1 root root       70 Apr 22 01:02 bin
-rwxrwxr-x 1 root root    11384 Feb 11  2014 bin_steamdeps.py
-rw-r--r-- 1 root root  3677776 Apr 22 01:00 bootstrap.tar.xz
drwxrwxr-x 1 root root      100 Apr 22 01:02 clientui
drwxrwxr-x 1 root root     1398 Apr 22 01:02 controller_base
-rwxrwxr-x 1 root root      718 Nov 18 21:19 fossilize_engine_filters.json
drwxrwxr-x 1 root root     5526 Apr 22 01:02 friends
-rwxrwxr-x 1 root root  1415528 Mar 24 19:24 GameOverlayRenderer64.dll
drwxrwxr-x 1 root root    26388 Apr 22 01:02 graphics
drwxrwxr-x 1 root root      204 Apr 22 01:02 legacycompat
drwxr-xr-x 1 root root       94 Apr 22 01:02 linux32
drwxrwxr-x 1 root root       58 Apr 22 01:02 linux64
drwxrwxr-x 1 root root     4394 Apr 22 01:02 package
drwxrwxr-x 1 root root     7518 Apr 22 01:02 public
drwxrwxr-x 1 root root    11054 Apr 22 01:02 resource
drwxrwxr-x 1 root root     2358 Apr 22 01:02 servers
drwxrwxr-x 1 root root       22 Apr 22 01:02 steam
-rwxrwxr-x 1 root root 22417616 Mar 24 19:24 steamclient64.dll
-rwxrwxr-x 1 root root 19072872 Mar 24 19:24 steamclient.dll
-rwxrwxr-x 1 root root      857 Oct  8  2013 steamdeps.txt
-rwxrwxr-x 1 root root     1316 Jul 10  2019 steam_msg.sh
-rwxrwxr-x 1 root root    23057 Jan  2 18:02 steam.sh
-rwxrwxr-x 1 root root    49827 Jun  1  2018 steam_subscriber_agreement.txt
drwxrwxr-x 1 root root      316 Apr 22 01:02 steamui
drwxrwxr-x 1 root root       16 Apr 22 01:02 tenfoot
-rwxrwxr-x 1 root root      405 Dec 24  2013 ThirdPartyLegalNotices.css
-rwxrwxr-x 1 root root    25088 Dec 17  2013 ThirdPartyLegalNotices.doc
-rwxrwxr-x 1 root root   202978 May  6  2019 ThirdPartyLegalNotices.html
drwxr-xr-x 1 root root     2006 Apr 22 01:02 ubuntu12_32
drwxrwxr-x 1 root root     1612 Apr 22 01:02 ubuntu12_64

$ ls -l ~/.steam/root/steamapps
total 12
-rwxrwxr-x 1 user user  763 Apr 26 06:47 appmanifest_40.acf
-rwxrwxr-x 1 user user 1015 Apr 26 07:16 appmanifest_70.acf
drwxrwxr-x 1 user user   18 Apr 25 04:21 common
drwxrwxr-x 1 user user    0 Apr 26 06:47 downloading
-rwxrwxr-x 1 user user  274 Apr 26 07:57 libraryfolders.vdf
drwxrwxr-x 1 user user    4 Apr 25 04:23 shadercache
drwxrwxr-x 1 user user    0 Apr 25 04:20 sourcemods
drwxrwxr-x 1 user user    0 Apr 26 06:47 temp

Am I reading this correctly? ls ~/.steam/root doesn't list steamapps as a directory and yet ls ~/.steam/root/steamapps succeeds? That's a yikes. I am not sure if this is even POSIX compliant.

I still don't understand, what functionality does this achieve that can't be solved with symlinks. For example, why wouldn't something like this work:

# Create a user-writable steamapps directory
mkdir -p ~/.steam/root/steamapps

# Symlink all the system-wide read-only files and folders
ls /usr/libexec/steam | xargs -I{} ln -s /usr/libexec/steam/{} ~/.steam/root/{}

producing something like

$ ls -l ~/.steam/root
total 45832
lrwxrwxrwx 1 user user       70 Apr 22 01:02 bin              -> /usr/libexec/steam/bin
lrwxrwxrwx 1 user user    11384 Feb 11  2014 bin_steamdeps.py -> /usr/libexec/steam/bin_steamdeps.py
lrwxrwxrwx 1 user user  3677776 Apr 22 01:00 bootstrap.tar.xz -> /usr/libexec/steam/bootstrap.tar.xz
lrwxrwxrwx 1 user user      100 Apr 22 01:02 clientui         -> /usr/libexec/steam/clientui

             ... <one symlink for each file and directory in /usr/libexec/steam> ...

drwxr-xr-x 1 user user       70 Apr 24 20:01 steamapps

Are you perhaps suggesting that current package managers don't "install steam system-wide", because the (globally installed) steam executable "manually" downloads libraries and updates and stuff into each users' directory instead of making the system package manager download those?

If that's what you are really trying to achieve, then I can only wish you good luck. IMHO, trying to fight with an application that wants to manage its own updates is a loosing battle (unless the application author actually wants to support such a use case, which Valve clearly doesn't).

I'm willing to fight the battle, the current application's behavior is just unacceptable.

Other companies behind closed-source programs provide proper packages, an example is AnyDesk.

The XDG Base Directory Specification (informally) tells you to "put files into their respective base directories instead of stuffing them all into $HOME/.shittyapp". The FUSE shim that you are proposing doesn't remove ~/.steam from your home dir. Your shim (might) solve the "organize files into their respective base directories" part, but it doesn't address the fact that Steam is still expecting to find a .steam directory in your home.

Consider that you can create the directory and delete it right after Steam quits.

Please note that my program is not looking for ~/.steam specifically, allowing you to completely get rid of the infamous directory.

See OpenMandrivaSoftware/steam_xdg_enforcer@ce7fd252adb4b3df4b8bb24bf4eb4300d2ef875d.

Am I reading this correctly? ls ~/.steam/root doesn't list steamapps as a directory and yet ls ~/.steam/root/steamapps succeeds? That's a yikes. I am not sure if this is even POSIX compliant.

Is there anything that is actually 100% POSIX compliant?

From a user's point of view it would be confusing to see steamapps there, since in reality it resides in another directory.

I still don't understand, what functionality does this achieve that can't be solved with symlinks. For example, why wouldn't something like this work:

# Create a user-writable steamapps directory
mkdir -p ~/.steam/root/steamapps

# Symlink all the system-wide read-only files and folders
ls /usr/libexec/steam | xargs -I{} ln -s /usr/libexec/steam/{} ~/.steam/root/{}

producing something like

$ ls -l ~/.steam/root
total 45832
lrwxrwxrwx 1 user user       70 Apr 22 01:02 bin              -> /usr/libexec/steam/bin
lrwxrwxrwx 1 user user    11384 Feb 11  2014 bin_steamdeps.py -> /usr/libexec/steam/bin_steamdeps.py
lrwxrwxrwx 1 user user  3677776 Apr 22 01:00 bootstrap.tar.xz -> /usr/libexec/steam/bootstrap.tar.xz
lrwxrwxrwx 1 user user      100 Apr 22 01:02 clientui         -> /usr/libexec/steam/clientui

             ... <one symlink for each file and directory in /usr/libexec/steam> ...

drwxr-xr-x 1 user user       70 Apr 24 20:01 steamapps

It's unclean and could also tank performance, as every single symlink has to be resolved.

Also, with FUSE you can deal with entries that don't exist yet or that are replaced.

@davidebeatrici Just to clarify before testing, how does your program deal with Steam installations moved elsewhere on the machine?

For example, currently the only things to do with Steam that reside in my HOME directory are the .steam* symlinks and directory which I wish to get rid of. Everything else to do with my Steam installation sits in one /extra/user/Games/Steam directory as this benefits from being located on an NVMe drive (mounted at /extra) instead of the hard disk used for /home.

Would the enforcement program decide to suddenly rearrange things or will it retain the existing setup somehow?

Assuming you have created a symlink from ~/.steam to /extra/user/Games/Steam, you can retain your current setup as follows:

export STEAM_INSTALL_DIR="/extra/user/Games/Steam"
export STEAM_DATA_DIR="/extra/user/Games/Steam"
export STEAM_RUN_DIR="${XDG_RUNTIME_DIR}/Steam"

MOUNT_POINT="${STEAM_RUN_DIR}/.steam"

mkdir -p "${MOUNT_POINT}"

steam_xdg_enforcer "${MOUNT_POINT}"

ORIG_HOME="${HOME}"

export HOME="${STEAM_RUN_DIR}"
# Run Steam
export HOME="${ORIG_HOME}"

umount "${MOUNT_POINT}"

The only change consists in steam.pid, steam.pipe and steam.token being created in /var/run/<uid>/Steam.

Not sure if it's due to the new beta update or just me being generally dumb, but I'm having more trouble than I was hoping to have actually setting up a proper wrapper script to use this. I might just have to wait until the README gets more fleshed out before I can make sense of how to set it up properly.

What issue(s) are you encountering?

I'll send an issue report your way with the output I'm getting. The example wrapper script simply doesn't start the Steam beta client up for me since it can't load steamui.so for whatever reason.

EDIT: Never mind, I understand now. It seems I need to actually have the various 32-bit libraries Steam uses installed on my machine in order to use the example wrapper script with the given LD_LIBRARY_PATH.

You should use the script I wrote for you here, the example one is strictly for systems that have all required dependencies (both 32 bit and 64 bit).

Perfect! Thanks a ton.

No problem! Please let me know whether you need further help, feel free to open an issue in the program's repository.

Ten years passed, and Steam seems still does not obey XDG...

If it's been over a decade, it's safe to say valve/steam won't care.

At this point it might be easier to give up on this issue and see what can be done on the XDG side for non-compliant apps.

Maybe automatically moving it and creating a sylink at the old/original location with an official XDG tool, or amending the XDG Spec to take this into account.

If Valve doesn't care about XDG specs, then they should close this issue as such. There's no point in illuding people or collecting near-spam messages.

here's a port of @mateusauler's wrapper script for those using the fish shell

#!/usr/bin/env fish

set OLDHOME $HOME
set HOME $XDG_DATA_HOME/Steam/fakehome # Replace this with where you want it to be

# Replaces every / of the first argument with \/
function replace_slash
    echo $argv | sed "s/\//\\\\\//g"
end

# Symlink a file to the fake home
function link_dir
    # Replace OLDHOME with HOME in the link name
    set link_name $(echo $argv | sed "s/^$(replace_slash $OLDHOME)/$(replace_slash $HOME)/")

    # Creates the link's parent directory and symlinks it
    mkdir -p $(dirname $link_name)
    [ ! -d $link_name ] && ln -s $argv $link_name
end

mkdir -p $HOME

link_dir $XDG_DATA_HOME # ~/.local/share
link_dir $XDG_CACHE_HOME # ~/.cache
link_dir $XDG_CONFIG_HOME # ~/.config
link_dir $OLDHOME/.icons # ~/.icons (lxappearance's mouse cursor theme)

# If .steam exists in ~/ and not in the fake home, move it to the fake home
[ -d $OLDHOME/.steam ] && [ ! -d $HOME/.steam ] && mv $OLDHOME/.steam $HOME/

exec /usr/bin/steam "$argv"

and may we get spec compliance soon

I've recently switched to NixOS and ported this script to my nix config.

Here's an updated version for bash:

#!/usr/bin/env bash

FAKEHOME=$XDG_DATA_HOME/Steam/fakehome # Replace this with where you want it to be

# Symlink a file to the fake home
link_dir() {
	# Replace HOME with FAKEHOME in the link name
	link_name=$(echo $1 | sed "s|^$HOME|$FAKEHOME|")

	# Creates the link's parent directory and symlinks it
	mkdir -p $(dirname $link_name)
	[ ! -d $link_name ] && ln -s $1 $link_name
}

mkdir -p $FAKEHOME

link_dir $XDG_DATA_HOME   # ~/.local/share
link_dir $XDG_CACHE_HOME  # ~/.cache
link_dir $XDG_CONFIG_HOME # ~/.config
link_dir $HOME/.icons     # ~/.icons (lxappearance's mouse cursor theme)

# If .steam exists in ~/ and not in the fake home, move it to the fake home
[ -d $HOME/.steam ] && [ ! -d $FAKEHOME/.steam ] && mv $HOME/.steam $FAKEHOME/

HOME=$FAKEHOME exec /usr/bin/steam $@

As we observe the world, we see our home.
We see the chaos, the order;—
We see things we missed, things we dreaded.

Finally, we glance at our dotfiles;
with a terrified yelp, we see the ruthless XDG non-compliance;—
As though valve were trying out a new pseudoscience;—
A million different dotfile styles.

Why cant they leave us alone?
The risk they are trying to make us take;—
Why put us in the danger-zone?
They fear that them we shall forsake.

And you know what folks? I pretty darn close to forsaking the hell out of steam...

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/1890#issuecomment-1777105251

@GotaLoveFiraCode i shed a tear reading this :cry:

Its weird for me that people dont give a ding dong about what sense there is to request xdg support. How is there any benefit to even consider it. Moving 3-4 hidden files to some dir with no benefit other than it being nice and it even being worth risking anything at all.

Its mental that people dont give a ding dong about why on earth one would even bother with xdg support as it would break left and right and not be a matter of valve just moving 3-4 files. What on earth is there even to gain by doing this? 3-4 files not being in your homedir? What on earth are you peeps smoking lol

@foololol it wouldn't be that hard? it's probably written in c++, so it would be as simple as:

if( getenv("STEAM_HOME" ) {
    let steam_dir = /* The value of STEAM_HOME */;
} else {
    let steam_dir = "$HOME/.steam";
}

You do know that its not only steam running when you run a game ? wtf

There have been numerous shims presented in this thread that almost acheive the desired support minus some pendantics about what belong in CONFIG and what belongs in DATA. I have been using a launch script that sets HOME=$XDG_DATA_HOME/steamhome before launching steam and it breaks absolutely 0 functionality. The bare minimum Valve could do is an officially supported variation on that pattern. It's MY home directory, not Valve's.

@foololol you do know that steam is literally the thing running the games, right?

I did not know that. Whats this thing. -and how are games running on this thing? And how does it all make it so simple for xdg support?

It's MY home directory, not Valve's.

Its not on Valve that YOUR installing THEIR software on YOUR system...? whats the sense in this argument?

And how would even xdg support change that fact? It would probably still be in your home dir. Try hardlinking a file left and right in your home dir. Its probably a matter of something else than a dir.

Lets filip it: whats the gain being worth the cost? You not seeing 3-4 files in your home is not exactly worth the cost of even a single game bricking on a engine due to some hard code.

Probably best to not engage with a fresh account who has no other activity than calling people in this thread "mental".

Thank you for pointing that out. Got quite carried away and my intention was mostly to see if someone was able to make some argument for how it make sense other than it being nice and worth bricking even a single game.

You could also disable "show hidden files and folders" in gui and simply ls without hidden files. Your not treating this as hidden files or dirs at all. Its hardly a spec thats adopted and most apps dont support it. If the argument is that a spec should be followed simply because some minority want that, everyone can make the same argument for any spec? Or is it only XDG base dir spec that is allowed that argument? Its Linux, no one agrees on anything and a spec from freedesktop even less. Uniformity is hardly to be expected.

I cant see anyone with a single argument for why its worth the cost involved with bricking games. These claiming its only a matter of env vars arent helping their case.

Point being, it would probably be better if there were some arguments other than some few wanting a neat home. -and you dont care if it bricks games or costs. No wonder its not implemented and it absolutely shouldnt unless someone can make the case.

Anywho, cheers. my apologies.

Wanted to add a +1 of sorts to this one myself. I am also a ~/ purist and I'm losing my mind with the three steam entries in my sacred folder.

With many programs, I modify my .desktop entry with the HOME environment variable to a neat directory like ~/.local/application/ and it's a bit hacky, but everything works just fine like this and I am sated.

However, the nature of Steam being a manager for many applications, and all of which have their own .desktop entries, the above solution loses its merit.

So I beg, please consider implementing this QOL update. 🙏

Will probably fall on deaf ears but here's my +1 . Surely not that hard to implement. This is why FOSS is always >

Been cleaning my system and am stuck myself at this "clutter" +1 for adding support.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/1890#issuecomment-1693548157

This is great, you can also modify it to launch steam-screensaver-fix-runtime instead of steam as that also fixes another issue that steam has disables the screenlock even when no game is running.

I edited my i3 keybind to launch it like this:

bindsym $mod+F6 exec --no-startup-id pgrep steam && i3-msg "[class=steam] focus" || exec ~/.config/i3/scripts/fixsteam.sh | notify-send -t 2000 "Launching Ruthless non-XDG Compliant Software: Steam" "(Also fucks your screensaver lol)"

Edit: I changed the end of the script so that it cleans the homedir if steam creates the directories again like if you had launched it from the terminal, the sleep 8 is needed because it takes a while for steam to quit:

# If .steam exists in ~/ and not in the fake home, move it to the fake home
if [ -d $HOME/.steam ] && [ ! -d $FAKEHOME/.steam ]; then
    mv $HOME/.steam $FAKEHOME/

# If .steam exists in ~/ and in fake home trash the home steam dirs
elif [ -d $HOME/.steam ] && [ -d $FAKEHOME/.steam ]; then
    killall steam
    sleep 8 && {
        trash $HOME/.steampid
        trash $HOME/.steampath
        trash $HOME/.pki
        trash $HOME/.steam
        notify-send -t 2000 "Steam has done it again" 
    }
fi

if [ ! -d $HOME/.steam ] || [ -d $FAKEHOME/.steam ]; then
    HOME=$FAKEHOME exec /usr/bin/steam-screensaver-fix-runtime $@
fi

At this point, this shits gonna be implemented after GTA VI... XD

(Which is never... Like Hollow Knight Silksong)

Oh wow, Would you look at the Dates?
IT'S BEEN 10 YEARS 11 MONTHS 8 DAYS!
Respectfuly, WTF!
It it that Hard to Implement?

bruh...

anyone wanna start counting bumps?

Please, stop commenting on this thread unless you have something actually new to add to the discussion. At least 84 people get notifications every time someone comments on this thread.

And don't feed the trolls.

Let's run through the files that Steam creates within $HOME for a moment. We have the following:

• A ~/.steam directory, mostly containing symlinks to different directories within the Steam installation, but also containing a few runtime files such as a PID file, a named pipe and a token file. The registry.vdf file also lies there, which is presumably either a data or state file.
• A ~/.steampid symlink which is just an alternate location for ~/.steam/steam.pid.
• A broken ~/.steampath symlink which is supposedly there as a workaround for games shipping too old of a Steamworks redistributable with them.

The ideal thing to do, if Steam really needs to continue making use of these files as they are, would be the following:

• Move the majority of the ~/.steam directory — namely, the symlinks — to an $XDG_CONFIG_HOME/steam directory instead. Presumably, the symlinks act as something of a config indicating where the actual Steam installation is located, since they update based on the install location that the user chooses if the installation is missing from where the symlinks are already pointing to.
• Move the steam.pid, steam.pipe and steam.token files from ~/.steam to $XDG_RUNTIME_DIR[/steam], since they are only meant to be runtime files.
• Move the ~/.steam/registry.vdf file to $XDG_STATE_HOME/steam/registry.vdf since it looks like this is more of a state file rather than a data file.
• If possible, find an alternative location for ~/.steampath that conforms to the spec. I'm not entirely sure whether this would be considered a file for $XDG_CONFIG_HOME based on the rest of the symlinks, or for $XDG_STATE_HOME.
• If possible, do away with ~/.steampid altogether. When is this even being used instead of ~/.steam/steam.pid directly?

I'm gonna be honest though... If Valve is keeping .steampath for compatibility reasons, then why would they ever move any of the other directories to support the XDG_SPEC?
I'd like to believe it might come to fruition, it's just... Think of it from the standpoint of a company. This is purely an aesthetic issue and devoting precious developers to implement this will only cost them with no real benefit whatsoever...

Depending on how they architected their software (hardcoded .steam everywhere in spaghetti code fashion or have a static function returning the directory for global calls) it might not even be feasible at this point for them...

I agree with @Eclextic. And I also believe that it would be wrong to implement this, since it could potentially break any number of games for little to no benefit for the average user. I'd go as far as to say this should be closed as "won't fix".

But, for those of us who care about it and are willing to troubleshoot a few broken games, here's the most recent version of my wrapper script (maybe I should create a repo or a gist for it?):

#!/usr/bin/env bash

# Where will steam store its files?
export fakeHome=$XDG_DATA_HOME/Steam/fakehome
# The location of steam's real binary
steampath=/usr/bin/steam

# Symlink a file to the fake home
link_dir() {
	# Replace HOME with FAKEHOME in the link name
	link_name=$(echo $1 | sed "s|^$HOME|$fakeHome|")
	
	# Creates the link's parent directory and symlinks it
	mkdir -p $(dirname "$link_name")
	if [ ! -d "$link_name" ]; then
		ln -s "$1" "$link_name"
	fi
}

mkdir -p $fakeHome

# Remove every link in the fake home
find $fakeHome -maxdepth 1 -type l -delete

# If .steam exists in ~/, move it to the fake home, updating the newer files
if [ -d $HOME/.steam ]; then
	mv -uf $HOME/.steam/* $fakeHome/.steam/
	rmdir $HOME/.steam
fi
# Remove runtime steam files from the user's home
rm -f $HOME/.steampath $HOME/.steampid

# Export the function so we can use it in a new bash context
export -f link_dir
# Link every file in the root of the home directory to the fake home
find $HOME -maxdepth 1 | xargs --max-procs=$(nproc) -I{} bash -c 'link_dir "$0"' {}

HOME=$fakeHome exec $steampath $@

I now use a better solution that is more permanent, won't get overwritten by updates, etc

the xdg base dir spec says that user binaries should go in ~/.local/bin. So just make the directory and add this to your zshenv or bashrc or whatever you use for your shell:

export PATH="$HOME/.local/bin:$PATH"

And now place a script named steam on that dir with the following content:

#!/bin/sh

FAKEHOME=$HOME/.local/FAKEHOME # Replace this with where you want it to be

# Start program at fakehome location
HOME=$FAKEHOME DEBUGGER="steam_sdl_injection.sh" /usr/bin/steam-runtime $@ ||
HOME=$FAKEHOME /usr/bin/steam-runtime $@ ||
notify-send "App not found"

It will first try to use steam-screensaver-fix if you have it installed, if not it will just launch the regular steam. And if neither is found it will notify of that error.

By placing that script first in PATH, steam will always launch at the fakehome location, you can just go to your terminal and type steam and it will launch as always. make sure to also place a symlink in that same dir named steam-runtime pointing to the steam script.

Now the desktop entry of Steam in /usr/share/applications it set to run Exec=/usr/bin/steam-runtime %U

To fix that issue you can just copy the desktop entry of steam from /usr/share/applications to your XDG_DATA_HOME/applications dir and edit the launch option to just say Exec=steam-runtime %U

That way steam will always be launched at the fakehome location, and the user desktop entries will overwrite the ones in usr from showing.

That is it, we didn't even need to use sudo to fix this issue. Make sure that the fake home of steam has the necessary symlinks to all the directories that steam needs access to, you can also add that function to the script if want to.

EDIT: I ended up making a script that fixes this automatically (you still need to make sure ~/.local/bin is in PATH):

https://github.com/Samueru-sama/fixsteam

It also applies the screensaver-fix on its own without depending on the aur package to be installed.

The above fix does not work on FreeBSD using the Steam port.

Welcome back gentlemen, I hope to see you again in 2034 :saluting_face:

The above fix does not work on FreeBSD using the Steam port.

Welcome back gentlemen, I hope to see you again in 2034 🫡

If you want open an issue detailing what doesn't work and I will see what I can do.

This will likely never happen as there are probably things that depend on those dotfiles existing.

I ended up replacing STEAMCONFIG=~/.steam with STEAMCONFIG="$XDG_CONFIG_HOME"/steam
in bin_steam.sh (on Arch /usr/sbin/bin_steam.sh), this sets up the folders.
Just place it in your XDG_BIN_HOME and make sure that it is before the original location in PATH.

edit: ok, i admit, i didn't yet test before i wrote. /usr/bin/steam calls /usr/lib/steam/steam, which is a symlink to /usr/lib/steam/bin_steam.sh, which in turn is a dublicate of /usr/sbin/bin_steam.sh. What a mess, folder and broken symlinks still get created even if launched directly from the modified script. I think this needs a rewrite of the whole pipeline. Tommorow is sunday, something to do.

editx2:

• bin_steamdeps.py goes to great lenths to determine architecture & co to install/update/fix dependencies via pkexec, no clue where that goes called.
• launcherutils.py is merely a compatibility shim for old Python versions (Debian).

What's left is bin_steam.sh and the steam.sh in ~/.local/share/Steam. That one has 800 lines of if/else, could take a while to understand. While i'm at it, i'll merge the two and create a minimal, easy to understand steam-launcher.

These days I just run steam in bubblewrap (like flatpak does) and just give it a fake home directory to live in. This has the added benefit that some games that run natively but pick hardcoded locations still (i.e. ~/.config/StardewValley) live in that fake home directory as well. Here's an example you can start hacking on, which I had on Gentoo:

#!/bin/bash

set -euxo pipefail

args=(
    --die-with-parent

    --dev-bind /dev /dev
    --proc /proc
    --bind /run /run
    --bind /sys /sys
    --tmpfs /tmp

    --bind "${HOME}"/my-fake-home-dir "${HOME}" # !!!!!!!! <- CHANGE THIS
    --chdir "${HOME}"

    # customisations on these don't need to go into your steam bwrap
    # it will more likely break things than do anything positive
    --unsetenv XDG_CACHE_HOME
    --unsetenv XDG_CONFIG_HOME
    --unsetenv XDG_DATA_HOME
    --unsetenv XDG_STATE_HOME

    # https://github.com/flatpak/flatpak/blob/be2de97e862e5ca223da40a895e54e7bf24dbfb9/common/flatpak-run.c#L277
    --tmpfs /tmp/.X11-unix
)

install -m 1777 -d /tmp/dumps
args+=(--bind-try /tmp/dumps /tmp/dumps)

# NOTE: might wanna add /opt if you need it for electron apps, dotnet (ffxiv), etc
for dir in /bin /etc /lib /lib64 /sbin /usr /var; do
    args+=(--ro-bind "${dir}" "${dir}")
done

if [[ "${DISPLAY}" == *:* ]]; then
    display_nr="${DISPLAY/#*:}" # strip host
    display_nr="${display_nr/%.*}" # strip screen
    local_socket=/tmp/.X11-unix/X"${display_nr}"
    args+=(--ro-bind-try "${local_socket}" "${local_socket}")
fi

# NOTE: depending on how you launch X11 you might want this unconditionally
if [[ "${XAUTHORITY:-}" == /tmp/* ]]; then
    args+=(--ro-bind-try "${XAUTHORITY}" "${XAUTHORITY}")
fi

exec bwrap "${args[@]}" -- /usr/bin/steam -disable-cef-sandbox "$@"

Make sure to substitute your own paths in before running, of course, and then drop this as steam in your $PATH. Depending on how your distribution ships Steam, you might also need to copy the Steam .desktop file in the user-specific location and change Exec=/usr/bin/steam to Exec=steam.

NixOS

I based a good part of this script off of NixOS's buildFHSEnv output. If you're using NixOS, you can skip all this trouble and instead override the Steam package, like so:

pkgs.steam.override {
  extraBwrapArgs = [
    "--bind $HOME/my-fake-home-dir $HOME"
    "--unsetenv XDG_CACHE_HOME"
    "--unsetenv XDG_CONFIG_HOME"
    "--unsetenv XDG_DATA_HOME"
    "--unsetenv XDG_STATE_HOME"
  ];
}

You can also pass in this custom steam package to other packages that take a steam argument like XIVLauncher and it works good.

GNU Guix System

If you're using Steam from the nonguix repo it already has sandboxing by default.

Bumpasaurus

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/1890#issuecomment-2367103614

@0x08088405
So if i use nixos its enough to override the package, or do i still need to sandbox it?
I just have to change "my-fake-home-dir" with any folder i created for that right? e.g. $HOME/.config/steam
Thats where i would like to have it.

So if i use nixos its enough to override the package, or do i still need to sandbox it?

@UnknownHiker the NixOS package for Steam is "sandboxed" in the sense that it expects an FHS-compliant environment so it's ran inside bwrap with the expected locations existing, but all folders under / are transparently passed through so they're not "sandboxed" in the sense that it's isolated from the rest of your system. If your goal is only a custom home directory, it is enough to override the package, yes.

@0x08088405 I'm getting the following with your script, it seems like it's still finding the real $HOME(?):

/home/REDACTED/.local/share/Steam/steam.sh: line 900: /home/REDACTED/.local/share/Steam/ubuntu12_32/steam: cannot execute: required file no
t found

Edit: note that the Steam folder is not really there, so it is mistaken about where it's located

This is ridiculous. We will genuinely see GTA VI before Steam adheres to XDG standards.
It's unreasonable to say that Valve hasn't seen this... after 12 years. Why won't they just interact with it?
Is it so difficult to say "No, piss off"?
That is my biggest point of confusion. Forget the simple fix, I cannot comprehend why a Valve employee has not interacted with this 12 year old issue.

We will genuinely see GTA VI before Steam adheres to XDG standards.

... and it will explicitly block Linux like GTA V does as of a few months ago.

I'm sure someone has already done this but here is a simple wrapper that preserves the real .local and .config directories using (even more) symlinks:

#!/usr/bin/env bash
fake_home=/tmp/steam_home

if [ ! -d $fake_home ]; then
    mkdir -p $fake_home
    ln -s "$HOME"/{.cache,.config,.local} $fake_home
fi

export HOME=$fake_home
exec /usr/lib/steam/bin_steam.sh "$@"

The script I personally ended up using is also very simple (and POSIX xD):

#!/bin/sh

APPHOME=$XDG_STATE_HOME/FakeSteamHOME
APPEXEC=/usr/bin/steam
mkdir -p $APPHOME

if [ $@ ]; then
	HOME="$APPHOME" "$APPEXEC" "$@"
else
	HOME="$APPHOME" "$APPEXEC" -nochatui -nofriendsui -silent
fi

There is a tool named boxxy to redirect files of programs, but I don't know how much it would break other programs.

This is a feature request to natively follow the XDG Base Directory Specification. Posting "alternative fixes" is not helpful.

Posting alternative fixes is unfortunately the only solution when Valve hasn't solved the original problem for a decade.

bump :steamhappy:

Bump (this will never happen -_-)

in ${XDG_DATA_DIR-$HOME/.local/share}/Steam/steam.sh, you can find

# We use ${HOME%/}/.steam for bootstrap symlinks so that we can easily
# tell partners where to go to find the Steam libraries and data.
# This is constant so that legacy applications can always find us in the future.
STEAMCONFIG="${HOME%/}/.steam" # Drop tailing slash in home folder if it exists.

I don’t know who these “partners” and “legacy applications” are, maybe knowing that would help.

I wonder if that is for application external or internal to steam. If it's only internal, then it could probably be solved with adjustments to the runtime.

Is .mono also part of steam ?

🞈 lt -5 .mono                                                                   took 9s 21:44
 .mono
└──  registry
    ├──  CurrentUser
    │   └──  software
    │       └──  terraria
    └── 󰡯 last-btime

Is .mono also part of steam ?

no

Is there anything I can do about it ?

we cannot tell yuo wheter its ok to delete mono or not since only you know what you run on your pc and what you need .mono for, investigate, this is for steam not terraria/.net/mono

Is there anything I can do about it ?

This issue goes to a lot of people, so this isn't really the forum for discussing stuff unrelated to Steam, but no, you would have been looking for https://github.com/mono/mono/pull/12764 (courtesy of https://github.com/b3nj5m1n/xdg-ninja)

On the Steam runtime 3 beta client only ~/.steam and ~/.pki (which has been fixed in upstream Chromium) are created, however not all of it may be intentional (for example #13017).

Which has been fixed in upstream Chromium

Well, yes, but it's likely going to be another five years before everyone upgrades their CEF builds that far ahead.