[Feature Request] Follow XDG Base Directory Specification

[brl1214]

From a post on steam forums just linking it here.

Over in our group chat this has come up a few times already.

From a user who already has > 150 dot-files/directories in his home directory: Please, not another one! Since many years, there has been a standard for configuration/data/cache storage. Please follow it.

Simplest implementation (pseudo-code):
if (set(XDG_DATA_HOME))
dir=$XDG_DATA_HOME/Valve/Steam
else
dir=$HOME/.local/share/Valve/Steam
end if
Store everything that is now in $HOME/.steam into that directory.

If you want to get fancy, try to implement the whole specification and split Steam's data between XDG_CONFIG_HOME ($HOME/.config per default), XDG_DATA_HOME and XDG_CACHE_HOME ($HOME/.cache per default).

http://steamcommunity.com/app/221410/discussions/0/882965239742479108/
Original post.

[ghost]

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.

[dcbishop]

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.

[jleclanche]

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

[brl1214]

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

[ghost]

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.

[pfsmorigo]

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

[escondida]

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

[ghost]

+1

[escondida]

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.

[theKraid]

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

[Soapux]

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

[Lyude]

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.

[Jimbolino]

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.

[shubham-cpp]

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

[laydros]

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.

[felixsanz]

come on....... follow specs

[RJSent]

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

[Jimbolino]

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

[tiritto]

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

[itaranto]

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.

[Pablo1107]

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

[TheBearodactyl]

Replying to #1890 (comment)

@GotaLoveFiraCode i shed a tear reading this 😢

[foololol]

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.

[TheBearodactyl]

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";
}

[foololol]

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

[xeluior]

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]

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

[0x5c]

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

[foololol]

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.

[Drayux]

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

[mohakim]

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

[Peeajhay]

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

[Samueru-sama]

Replying to #1890 (comment)

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

[Eclextic]

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

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

[DaoistOak]

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?

[misterhackerman]

bruh...

[UltraBlackLinux]

anyone wanna start counting bumps?

[RuRo]

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.

[62832]

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?

[Eclextic]

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

[mateusauler]

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 $@

[Samueru-sama]

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.

[MantasXVIII]

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

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

[Samueru-sama]

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.

[Managor]

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

[Baerbeisser]

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.

[0x08088405]

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)

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

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.