Moved ~/.local/share/steam. Ran steam. It deleted everything on system owned by user.

[keyvin]

Edit: Please stop posting stupid image memes or unhelpful messages. This interferes with Valve's ability to sift through the noise and see if anyone can figure out what triggers it.

This may not be a common problem because I change all sorts of configuration about my system. The script in question does something in a really, really stupid way, but it probably doesn't trigger the fail scenario for every system because...

Original Bug:
I am not sure what happened. I moved the folder in the title to a drive mounted under /media/user/BLAH and symlinked /home/user/.local/steam to the new location.

I launched steam. It did not launch, it offered to let me browse, and still could not find it when I pointed to the new location. Steam crashed. I restarted it.

It re-installed itself and everything looked great. Until I looked and saw that steam had apparently deleted everything owned by my user recursively from the root directory. Including my 3tb external drive I back everything up to that was mounted under /media.

Everything important, for the most part, was in the cloud. It is a huge hassle, but it is not a disaster. If there is the chance that moving your steam folder can result in recursively deleting everything in the directory tree you should probably just throw up an error instead of trying to point to other stuff. Or you know, allow the user to pick an install directory initially like on windows.

My system is ubuntu 14.04, and the drive I moved it to was ntfs if its worth anything.

[doofy]

I am impressed how calm you stay about this. This is terrible. I just lost my home directory. All i did was start steam.sh with STEAM_DEBUG=1. I will investigate this and report back.

edit1: I suspect steam.sh got some bugs(does not check own variables) and when it tried to do scary things it crapped himself.
Line 468: rm -rf "$STEAMROOT/"*

edit2: It gets better. Seems on windows Steam is overeager too! https://support.steampowered.com/kb_article.php?ref=9609-OBMP-2526 (The warning part is interesting. Because everybody reads this before uninstalling...)

[doofy]

I am impressed how calm you stay about this. This is terrible. I just lost my home directory. All i did was start steam.sh with STEAM_DEBUG=1. I will investigate this and report back.

edit1: I suspect steam.sh got some bugs(does not check own variables) and when it tried to do scary things it crapped himself.
Line 468: rm -rf "$STEAMROOT/"*

edit2: It gets better. Seems on windows Steam is overeager too! https://support.steampowered.com/kb_article.php?ref=9609-OBMP-2526 (The warning part is interesting. Because everybody reads this before uninstalling...)

[Tele42]

I agree, that line minimally requires an exists and not null check for $STEAMROOT

[Tele42]

I agree, that line minimally requires an exists and not null check for $STEAMROOT

[keyvin]

#scary!

As an ex programmer, that really makes me chuckle. Can I at least get an apology from whoever committed that comment without adding a fix?

[keyvin]

#scary!

As an ex programmer, that really makes me chuckle. Can I at least get an apology from whoever committed that comment without adding a fix?

[onodera-punpun]

This also happened to me a few weeks ago, my entire home was deleted by the steam.sh script.

[onodera-punpun]

This also happened to me a few weeks ago, my entire home was deleted by the steam.sh script.

[pythoneer]

introduced here Sep 10, 2013 indrora/steam_latest@21cc141 line 359

rm -rf "$STEAMROOT/"* could be evaluated as rm -rf "/"* if $STEAMROOT is empty

but what exactly caused this? i've symlinked ~/.local/share/steam to, so i am a bit afraid to start steam :/

[pythoneer]

introduced here Sep 10, 2013 indrora/steam_latest@21cc141 line 359

rm -rf "$STEAMROOT/"* could be evaluated as rm -rf "/"* if $STEAMROOT is empty

but what exactly caused this? i've symlinked ~/.local/share/steam to, so i am a bit afraid to start steam :/

[TcM1911]

pythoneer,

I believe the issue starts on line 19:

# figure out the absolute path to the script being run a bit
# non-obvious, the ${0%/*} pulls the path out of $0, cd's into the
# specified directory, then uses $PWD to figure out where that
# directory lives - and all this in a subshell, so we don't affect
# $PWD

STEAMROOT="$(cd "${0%/*}" && echo $PWD)"
STEAMDATA="$STEAMROOT"

This probably returns as empty which mean: rm -rf "$STEAMROOT/"* is the same ass rm -rf "/"*.

[TcM1911]

pythoneer,

I believe the issue starts on line 19:

# figure out the absolute path to the script being run a bit
# non-obvious, the ${0%/*} pulls the path out of $0, cd's into the
# specified directory, then uses $PWD to figure out where that
# directory lives - and all this in a subshell, so we don't affect
# $PWD

STEAMROOT="$(cd "${0%/*}" && echo $PWD)"
STEAMDATA="$STEAMROOT"

This probably returns as empty which mean: rm -rf "$STEAMROOT/"* is the same ass rm -rf "/"*.

[pythoneer]

TcM1911,

that's my guess, too.

[pythoneer]

TcM1911,

that's my guess, too.

[ghost]

@keyvin @d00fy :
Line proceeded by # Scary! comment is in reset_steam() function, which is executed if and only if steam.sh is invoked with --reset as first argument.

Did any of you deliberately invoked that script with that option? If yes, why did you do it? What were you trying to achieve?

Removing user data is obviously wrong, no doubt about it. But if this happens only when user requests certain action, scope of that issue is somewhat limited.

[ghost]

@keyvin @d00fy :
Line proceeded by # Scary! comment is in reset_steam() function, which is executed if and only if steam.sh is invoked with --reset as first argument.

Did any of you deliberately invoked that script with that option? If yes, why did you do it? What were you trying to achieve?

Removing user data is obviously wrong, no doubt about it. But if this happens only when user requests certain action, scope of that issue is somewhat limited.

[jthill]

Yeah, they kinda need a readlink in there.

STEAMROOT=$(readlink -nf "${0%/*}")

[jthill]

Yeah, they kinda need a readlink in there.

STEAMROOT=$(readlink -nf "${0%/*}")

[jthill]

@minio Not "only if". reset_steam is also invoked by removing your .steam directory, since that sets INITIAL_LAUNCH

[jthill]

@minio Not "only if". reset_steam is also invoked by removing your .steam directory, since that sets INITIAL_LAUNCH

[soren121]

@minio A script accidentally running rm -rf /* is unacceptable in any scenario.

[soren121]

@minio A script accidentally running rm -rf /* is unacceptable in any scenario.

[gtmanfred]

it is like bumblebee all over again!
MrMEEE/bumblebee-Old-and-abbandoned#123

[gtmanfred]

it is like bumblebee all over again!
MrMEEE/bumblebee-Old-and-abbandoned#123

[Plaque-fcc]

I encountered Steam behaviour like with «--reset» for several times:
when I added «--reset» AND when I didn't. So — not «only if», can
confirm this, even having not deleted ~/.steam/ dir, too.

[Plaque-fcc]

I encountered Steam behaviour like with «--reset» for several times:
when I added «--reset» AND when I didn't. So — not «only if», can
confirm this, even having not deleted ~/.steam/ dir, too.

[prometheanfire]

wonder what the code path is to hit that rm without --reset

[prometheanfire]

wonder what the code path is to hit that rm without --reset

[indrora]

Can confirm; I have Steam bounded in an SELinux context ("Steam") and SELinux spits out:

Context violation: process /home/indrora/.local/share/Steam/ubuntu12_32/steam is only allowed in context steam_context, attempted to remove /boot/efi/grub/efistub

Ooops. I'll write a patch and PR it 🍺

[indrora]

Can confirm; I have Steam bounded in an SELinux context ("Steam") and SELinux spits out:

Context violation: process /home/indrora/.local/share/Steam/ubuntu12_32/steam is only allowed in context steam_context, attempted to remove /boot/efi/grub/efistub

Ooops. I'll write a patch and PR it 🍺

[indrora]

https://github.com/lrusak/steam_latest/pull/1 PR

[indrora]

https://github.com/lrusak/steam_latest/pull/1 PR

[johnv-valve]

Does anybody have reliable repro steps for this? I can easily add the checks for STEAMROOT being empty, but I would also like to fix the root cause if possible.

[johnv-valve]

Does anybody have reliable repro steps for this? I can easily add the checks for STEAMROOT being empty, but I would also like to fix the root cause if possible.

[rcxdude]

It will definitely fail if you run steam.sh as bash steam.sh. I don't know if that's the cause in this case. In terms of root cause, I would say you should use set -e, set -u, and similar options in order to make the script less likely to silently ignore errors.

[rcxdude]

It will definitely fail if you run steam.sh as bash steam.sh. I don't know if that's the cause in this case. In terms of root cause, I would say you should use set -e, set -u, and similar options in order to make the script less likely to silently ignore errors.

[ayust]

Using ${STEAMROOT:?} instead of $STEAMROOT would have helped, too.

(For those not familiar, ${FOO:?} is identical to $FOO except that it errors out automatically if $FOO is empty or unset.)

[ayust]

Using ${STEAMROOT:?} instead of $STEAMROOT would have helped, too.

(For those not familiar, ${FOO:?} is identical to $FOO except that it errors out automatically if $FOO is empty or unset.)

[ju2wheels]

Which is the same thing that would have happened had the unnecessary '/*' not been there anyway, it would have errored out. Its not necessary because the rm was set to recursive already...

if [ ! -z "${STEAMROOT}" ]; then
   rm -rf "${STEAMROOT}"
fi

[ju2wheels]

Which is the same thing that would have happened had the unnecessary '/*' not been there anyway, it would have errored out. Its not necessary because the rm was set to recursive already...

if [ ! -z "${STEAMROOT}" ]; then
   rm -rf "${STEAMROOT}"
fi

[rcxdude]

Here is a patch which enables set -e, set -u, and a few others, and then fixes up all the places where undefined variables are expected to be (as far as I can tell): https://gist.github.com/rcxdude/1f6257e0a965147a462c

[rcxdude]

Here is a patch which enables set -e, set -u, and a few others, and then fixes up all the places where undefined variables are expected to be (as far as I can tell): https://gist.github.com/rcxdude/1f6257e0a965147a462c

[mablae]

@rcxdude Come on. We are on github here. Do that in a PR please! Do not post whole patch files into issues... 👎

[mablae]

@rcxdude Come on. We are on github here. Do that in a PR please! Do not post whole patch files into issues... 👎

[dannyfallon]

@mablae There is no code on this repo, there is nothing to send in a PR against. A gist wouldn't have gone astray though 😄

[dannyfallon]

@mablae There is no code on this repo, there is nothing to send in a PR against. A gist wouldn't have gone astray though 😄

[slnovak]

@rcxdude: Please link to a Gist.

[slnovak]

@rcxdude: Please link to a Gist.

[sdt16]

@mablae How about instead of being a jerk, you link @rcxdude to some documentation.

[sdt16]

@mablae How about instead of being a jerk, you link @rcxdude to some documentation.

[Tele42]

@johnv-valve regardless of tracking down the cause of this, this rm line must be protected from future accidental gremlins due to the severity of the fail scenario.

[Tele42]

@johnv-valve regardless of tracking down the cause of this, this rm line must be protected from future accidental gremlins due to the severity of the fail scenario.

[mablae]

@dannyfallon Oh, sorry then...
@sdt16 I am sorry. Thought the code was on this repo ... Didn't wanted to be a "jerk" :)

[mablae]

@dannyfallon Oh, sorry then...
@sdt16 I am sorry. Thought the code was on this repo ... Didn't wanted to be a "jerk" :)

[Wapaca]

Does it happen only if you move ~/.local/share/steam ? #scary! :s

[Wapaca]

Does it happen only if you move ~/.local/share/steam ? #scary! :s

[joshenders]

The idiomatic way to do this in Bash is to use default variables as in ,"${var:-/sane/path}" or "${var:?}" as was already mentioned. While using set -u or similar could have prevented this mistake, it's lazy and considered bad style.

[joshenders]

The idiomatic way to do this in Bash is to use default variables as in ,"${var:-/sane/path}" or "${var:?}" as was already mentioned. While using set -u or similar could have prevented this mistake, it's lazy and considered bad style.

[doofy]

If steam really wants to act like a package manager it should only delete files created by itself.

@soren121 +1

[doofy]

If steam really wants to act like a package manager it should only delete files created by itself.

@soren121 +1

[ryenus]

Shell scripts can also have tests, see shunit2. I wish I used it instead of making mini/naive one myself.

[ryenus]

Shell scripts can also have tests, see shunit2. I wish I used it instead of making mini/naive one myself.

[damm]

it's 2015; I think we can do better than complex badly written shell scripts.

rm is dangerous; you should never use rm ${macro}/

[damm]

it's 2015; I think we can do better than complex badly written shell scripts.

rm is dangerous; you should never use rm ${macro}/

[mpnordland]

@d00fy Steam is essentially a package manager for your games.

[mpnordland]

@d00fy Steam is essentially a package manager for your games.

[carlosmcevilly]

@ju2wheels your snippet has a spurious 'D' in it, 'STEAMROOT' versus 'STEAMDROOT' -- so ${STEAMDROOT} will be empty and that code is going to end up starting at the current directory and doing a recursive delete from there.

Could be almost as bad depending what the current directory is. Let's hope nobody copy/pastes that snippet for actual use.

[carlosmcevilly]

@ju2wheels your snippet has a spurious 'D' in it, 'STEAMROOT' versus 'STEAMDROOT' -- so ${STEAMDROOT} will be empty and that code is going to end up starting at the current directory and doing a recursive delete from there.

Could be almost as bad depending what the current directory is. Let's hope nobody copy/pastes that snippet for actual use.

[soren121]

@mpnordland I think that's what he said.

[soren121]

@mpnordland I think that's what he said.

[neko]

Is this the new bumblebee?

[neko]

Is this the new bumblebee?

[nhuerta]

I hope no one is running this as root

[nhuerta]

I hope no one is running this as root

[hakusaro]

@d00fy I'm going to make the argument that while Steam is certainly at fault, you should definitely be using off site backups for this exact reason.

[hakusaro]

@d00fy I'm going to make the argument that while Steam is certainly at fault, you should definitely be using off site backups for this exact reason.

[DanielGibson]

I hope no one is running this as root

On a typical desktop Linux system that would only make it marginally worse - reinstalling the OS is less of a problem than losing all your data from $HOME

[DanielGibson]

I hope no one is running this as root

On a typical desktop Linux system that would only make it marginally worse - reinstalling the OS is less of a problem than losing all your data from $HOME

[arno01]

You are always welcomed to use a containerized Steam (no performance impact) in case you afraid it can damage anything on your system, except the Steam-related files itself of course --
https://hub.docker.com/r/andrey01/steam/

[arno01]

You are always welcomed to use a containerized Steam (no performance impact) in case you afraid it can damage anything on your system, except the Steam-related files itself of course --
https://hub.docker.com/r/andrey01/steam/

[dsohler]

Always put Steam in a 32 bit chroot in order to run it on a recent system (64 bits of course). Only game devs want 32 bit nowadays so a chroot is necessary anyways if you don't want to clutter your system with a shitload of multiarch stuff.

If you prevent steam from deleting all your data that's a bonus, too.

[dsohler]

Always put Steam in a 32 bit chroot in order to run it on a recent system (64 bits of course). Only game devs want 32 bit nowadays so a chroot is necessary anyways if you don't want to clutter your system with a shitload of multiarch stuff.

If you prevent steam from deleting all your data that's a bonus, too.

[mhalano]

In fact containers and chroot are very secure, but isn't the best option from user's POV. An application which sane scripts which doesn't delete all your files still is the best option. May be one day when Flatpak and Snap become a standard we can rethink this.

[mhalano]

In fact containers and chroot are very secure, but isn't the best option from user's POV. An application which sane scripts which doesn't delete all your files still is the best option. May be one day when Flatpak and Snap become a standard we can rethink this.

[Germano0]

@mhalano You have to consider that many devs on steam stop supporting Linux because they say "1% of our customers use Linux but they account for 50% of our support requests". In view of this steam should be distributed as a container to keep as much of the environment under control as possible.

Source?

[Germano0]

@mhalano You have to consider that many devs on steam stop supporting Linux because they say "1% of our customers use Linux but they account for 50% of our support requests". In view of this steam should be distributed as a container to keep as much of the environment under control as possible.

Source?

[dsohler]

An application which sane scripts which doesn't delete all your files still is the best option.

Yes, of course. But as long as the software needs 32 bit libs I'm not going to run it outside a chroot/container/whatever. I don't want to clutter my system with multiarch crap.

[dsohler]

An application which sane scripts which doesn't delete all your files still is the best option.

Yes, of course. But as long as the software needs 32 bit libs I'm not going to run it outside a chroot/container/whatever. I don't want to clutter my system with multiarch crap.

[polkovnikov-ph]

"1% of our customers use Linux but they account for 50% of our support requests"

No surprise. Most of players on Windows are kids, most of players on Linux are programmers. Also these are "bug reports" and not "support requests".

[polkovnikov-ph]

"1% of our customers use Linux but they account for 50% of our support requests"

No surprise. Most of players on Windows are kids, most of players on Linux are programmers. Also these are "bug reports" and not "support requests".

[Bengt]

@mhalano You have to consider that many devs on steam stop supporting Linux because they say "1% of our customers use Linux but they account for 50% of our support requests". In view of this steam should be distributed as a container to keep as much of the environment under control as possible.

Yeah, it is really a big problem for content creators to have an engaged audience. /s

[Bengt]

@mhalano You have to consider that many devs on steam stop supporting Linux because they say "1% of our customers use Linux but they account for 50% of our support requests". In view of this steam should be distributed as a container to keep as much of the environment under control as possible.

Yeah, it is really a big problem for content creators to have an engaged audience. /s

[ryanpcmcquen]

@ohjames, but it could. There isn't a lot of finality either way without more data. These users could be finding valid bugs, in which case they are doing the developers a service.

[ryanpcmcquen]

@ohjames, but it could. There isn't a lot of finality either way without more data. These users could be finding valid bugs, in which case they are doing the developers a service.

[dsohler]

An engaged audience does not equate to a large number of support requests.

Bug reports aren't support requests.

[dsohler]

An engaged audience does not equate to a large number of support requests.

Bug reports aren't support requests.

[polkovnikov-ph]

So some random guy said "An engaged audience does not equate to a large number of support requests" twice but I have no idea why this truism is being repeatedly asserted?

[polkovnikov-ph]

So some random guy said "An engaged audience does not equate to a large number of support requests" twice but I have no idea why this truism is being repeatedly asserted?

[kon14]

no they didn't, and you're being neither funny nor clever.

@ohjames He's just treating you with your own medicine.
Using some random dev's made up percentage fud as a fact is no better than what Garry Newman does.

But I guess now that you deleted your comments people can't actually support any of this, right?
Right, cause deleting your comments is definitely going to end this convo (whether you're being harassed justly or wrongfully).

In any case, this is all off-topic, isn't that so?

[kon14]

no they didn't, and you're being neither funny nor clever.

@ohjames He's just treating you with your own medicine.
Using some random dev's made up percentage fud as a fact is no better than what Garry Newman does.

But I guess now that you deleted your comments people can't actually support any of this, right?
Right, cause deleting your comments is definitely going to end this convo (whether you're being harassed justly or wrongfully).

In any case, this is all off-topic, isn't that so?

[simi]

@kisak-valve please can you lock this? It's getting really off-topic here.

[simi]

@kisak-valve please can you lock this? It's getting really off-topic here.

[ryanpcmcquen]

@simi, the issue is closed, but not fixed as well as it should be. Locking it is going to keep the issue from being re-opened and actually resolved.

[ryanpcmcquen]

@simi, the issue is closed, but not fixed as well as it should be. Locking it is going to keep the issue from being re-opened and actually resolved.

[kisak-valve]

I'd rather not lock issue reports if I don't need to. At this point, I'd need either a test case that causes this issue or a request from a Steam dev to re-open this issue.

Since there is over a hundred participants on this issue report, I'd like to see at least 25 thumbs up on @simi's request to lock this issue.

[kisak-valve]

I'd rather not lock issue reports if I don't need to. At this point, I'd need either a test case that causes this issue or a request from a Steam dev to re-open this issue.

Since there is over a hundred participants on this issue report, I'd like to see at least 25 thumbs up on @simi's request to lock this issue.

[mhalano]

If Valve properly fix the problem (is not that hard) the off-topic messages go away.

[mhalano]

If Valve properly fix the problem (is not that hard) the off-topic messages go away.

[ryanpcmcquen]

@kisak-valve, @craig-sanders has shown a fix here: #3671 (comment)

[ryanpcmcquen]

@kisak-valve, @craig-sanders has shown a fix here: #3671 (comment)

[hasufell]

@kisak-valve, @craig-sanders has shown a fix here: #3671 (comment)

Sorry, but none of you really understand the problem. The problem is not the lack of arbitrary sanity-checks, the problem is that recursive deletion is an inherently problematic operation, especially if it is non-interactive. That is also why no package manager out there will ever do rm -r in any way. You track the installed files and only ever remove known files, never directories and never recursive.

[hasufell]

@kisak-valve, @craig-sanders has shown a fix here: #3671 (comment)

Sorry, but none of you really understand the problem. The problem is not the lack of arbitrary sanity-checks, the problem is that recursive deletion is an inherently problematic operation, especially if it is non-interactive. That is also why no package manager out there will ever do rm -r in any way. You track the installed files and only ever remove known files, never directories and never recursive.

[simi]

@kisak-valve issue was marked as closed (and by your comment also as resolved) and it is here just for annoying offtopic discussion. I don't see any reason to keep it unlocked and keep offtopic discussion. I would like to stay watching this issue, but I don't care about offtopic.

Once there will be news, you can:

1. unlock
2. comment as member (even it is locked)

and interested people will get notification.

[simi]

@kisak-valve issue was marked as closed (and by your comment also as resolved) and it is here just for annoying offtopic discussion. I don't see any reason to keep it unlocked and keep offtopic discussion. I would like to stay watching this issue, but I don't care about offtopic.

Once there will be news, you can:

1. unlock
2. comment as member (even it is locked)

and interested people will get notification.

[h1z1]

I don't know if they enjoy the publicity and free labor or what but Valve will never fix problems like this, seriously there are many threads like it on github alone. Looking at steam.sh should make anyone cry in a corner.

There are lovely assumptions like this all over the place:

 # Save the prompt in a temporary file because it can have newlines in it
    tmpfile="$(mktemp || echo "/tmp/steam_message.txt")"

That is so wrong on so many levels but they've hardcoded things everywhere. I can only imagine what the Windows client is like.

This one just boggles my mind:

    # Set up the link to the source code
     ln -sf "$STEAM_RUNTIME/source" /tmp/source
     else
          echo $"STEAM_RUNTIME couldn't download and unpack $STEAM_RUNTIME_DEBUG_URL, falling back to $STEAM_RUNTIME"

Look around those lines and cry. The RUNTIME_DEBUG_URL is based on a grep with no error checking. Isn't even over SSL. Rather hilarious thing is they explicitly force http1.0 in download_archive anyway.

My point is there are so many places this bug can surface it's no wonder Valve are unable to fix it. I wouldn't personally go near a LAN with steam running.

[h1z1]

I don't know if they enjoy the publicity and free labor or what but Valve will never fix problems like this, seriously there are many threads like it on github alone. Looking at steam.sh should make anyone cry in a corner.

There are lovely assumptions like this all over the place:

 # Save the prompt in a temporary file because it can have newlines in it
    tmpfile="$(mktemp || echo "/tmp/steam_message.txt")"

That is so wrong on so many levels but they've hardcoded things everywhere. I can only imagine what the Windows client is like.

This one just boggles my mind:

    # Set up the link to the source code
     ln -sf "$STEAM_RUNTIME/source" /tmp/source
     else
          echo $"STEAM_RUNTIME couldn't download and unpack $STEAM_RUNTIME_DEBUG_URL, falling back to $STEAM_RUNTIME"

Look around those lines and cry. The RUNTIME_DEBUG_URL is based on a grep with no error checking. Isn't even over SSL. Rather hilarious thing is they explicitly force http1.0 in download_archive anyway.

My point is there are so many places this bug can surface it's no wonder Valve are unable to fix it. I wouldn't personally go near a LAN with steam running.

[dsohler]

Conclusion: They have absolutely no idea how to develop software for Linux-based operating systems.

[dsohler]

Conclusion: They have absolutely no idea how to develop software for Linux-based operating systems.

[hasufell]

Conclusion: They have absolutely no idea how to develop software for Linux-based operating systems

That is correct. And it's not even so much about the poor quality shell scripting. They don't use the opensource community to their benefit. They have no understanding of the ecosystem or the community.

There are lots of people out there that would rewrite their scripts for free and even collaborate on linux-specific steam code. Apart from the tons of suggestions here, there have also been numerous PRs about making the scripts POSIX compatible and whatnot. They have been ignored.

Linux is basically a platform where you get reviews, suggestions, code and even professional help for free. Except valve doesn't use it. That's not really a problem of "oh, I let my grandma write the bash scripts that handle safe user data removal", it's your huge ignorance of the specificities of a platform and its community. Something went wrong during your "linux agenda".

[hasufell]

Conclusion: They have absolutely no idea how to develop software for Linux-based operating systems

That is correct. And it's not even so much about the poor quality shell scripting. They don't use the opensource community to their benefit. They have no understanding of the ecosystem or the community.

There are lots of people out there that would rewrite their scripts for free and even collaborate on linux-specific steam code. Apart from the tons of suggestions here, there have also been numerous PRs about making the scripts POSIX compatible and whatnot. They have been ignored.

Linux is basically a platform where you get reviews, suggestions, code and even professional help for free. Except valve doesn't use it. That's not really a problem of "oh, I let my grandma write the bash scripts that handle safe user data removal", it's your huge ignorance of the specificities of a platform and its community. Something went wrong during your "linux agenda".

[polkovnikov-ph]

But it totally makes sense given the way Valve works internally. There was employee or a group that made the project, but now they are either not interested in it or not even employed anymore. Who will merge PRs, if nobody knows the code?

[polkovnikov-ph]

But it totally makes sense given the way Valve works internally. There was employee or a group that made the project, but now they are either not interested in it or not even employed anymore. Who will merge PRs, if nobody knows the code?

[craig-sanders]

@hasufell yes, keeping track of all files and deleting only known files when uninstalling is what a package manager should do.

Steam doesn't do that, and likely never will. Steam isn't a real package manager. It's a game library manager originally written for an OS where package management is an alien concept, where each program is installed by running its own installer program (and assumes it's the only program that will ever run on the system so can do whatever TF it wants to without caring about screwing up other software the user may have installed)....For all its flaws, Steam on windows is actually a great leap forward compared to that even if it does seem primitive and broken compared to standard practice on linux or mac. Hell, even on Linux you still get idiot devs telling users to ignore the package manager and just run make install or the insanely insecure curl URL | bash.

Anyway, as always, it's more useful to deal with things as they are, not as they would be in an ideal world. Without the magic ability to make steam work like a real package manager, having a bunch of paranoid sanity checks in front of anything that affects file deletion is the most useful thing to do....equalled only by:

1. fixing all the shell coding mistakes, including:

• The $" pointed out by @h1z1. That is not the only instance - there are 21 more in my copy of steam.sh as of today. $" is valid syntax in bash but I doubt very much that the script author's purpose was to do locale translation.
• failure to consistently and properly double-quote variables
• use of backticks rather than $(). and failure to double-quote $().

2. carefully examine every instance of rm -r in the script (7 according to grep -c) and make sure they're as safe as possible given the hackish nature of the script. Perhaps even write a safe_rm wrapper function that does some sanity checking (e.g. existence and ownership of dir), before doing a recursive deletion, and use that wherever rm -r is run.

3. the many newbie errors like:

• #!/usr/bin/env bash. bash is always in /bin on a linux system, also on OS X. and using env to find a script interpreter is brain-damaged.
• piping grep into grep and then into awk - this is never necessary as awk can do regular expression pattern matching all by itself, e.g. (simplified version of steam.sh line 594):
  ldd "$1" | grep X | grep -v Y | grep -v Z | awk '{print $1}'
  is better written as
  ldd "$1" | awk '/X/ && ! /Y|Z/ {print $1}'
  or perhaps even
  ldd "$1" | awk '/not found/ {print $1}'
  since that seems to be the purpose of that line.
• failure to program defensively - i.e. don't assume anything about the environment. a Q&D hack may be OK on someone's personal system, but not for code intended for distribution to others.

These mistakes and newbie errors are just what I've noticed from a casual glance at the script. There are undoubtedly many more.

[craig-sanders]

@hasufell yes, keeping track of all files and deleting only known files when uninstalling is what a package manager should do.

Steam doesn't do that, and likely never will. Steam isn't a real package manager. It's a game library manager originally written for an OS where package management is an alien concept, where each program is installed by running its own installer program (and assumes it's the only program that will ever run on the system so can do whatever TF it wants to without caring about screwing up other software the user may have installed)....For all its flaws, Steam on windows is actually a great leap forward compared to that even if it does seem primitive and broken compared to standard practice on linux or mac. Hell, even on Linux you still get idiot devs telling users to ignore the package manager and just run make install or the insanely insecure curl URL | bash.

Anyway, as always, it's more useful to deal with things as they are, not as they would be in an ideal world. Without the magic ability to make steam work like a real package manager, having a bunch of paranoid sanity checks in front of anything that affects file deletion is the most useful thing to do....equalled only by:

1. fixing all the shell coding mistakes, including:

• The $" pointed out by @h1z1. That is not the only instance - there are 21 more in my copy of steam.sh as of today. $" is valid syntax in bash but I doubt very much that the script author's purpose was to do locale translation.
• failure to consistently and properly double-quote variables
• use of backticks rather than $(). and failure to double-quote $().

2. carefully examine every instance of rm -r in the script (7 according to grep -c) and make sure they're as safe as possible given the hackish nature of the script. Perhaps even write a safe_rm wrapper function that does some sanity checking (e.g. existence and ownership of dir), before doing a recursive deletion, and use that wherever rm -r is run.

3. the many newbie errors like:

• #!/usr/bin/env bash. bash is always in /bin on a linux system, also on OS X. and using env to find a script interpreter is brain-damaged.
• piping grep into grep and then into awk - this is never necessary as awk can do regular expression pattern matching all by itself, e.g. (simplified version of steam.sh line 594):
  ldd "$1" | grep X | grep -v Y | grep -v Z | awk '{print $1}'
  is better written as
  ldd "$1" | awk '/X/ && ! /Y|Z/ {print $1}'
  or perhaps even
  ldd "$1" | awk '/not found/ {print $1}'
  since that seems to be the purpose of that line.
• failure to program defensively - i.e. don't assume anything about the environment. a Q&D hack may be OK on someone's personal system, but not for code intended for distribution to others.

These mistakes and newbie errors are just what I've noticed from a casual glance at the script. There are undoubtedly many more.

[aaronfranke]

bash is always in /bin on a linux system, also on OS X.

Many Linux distros store it in /usr/bin instead, along with everything else that usually goes in /bin.

[aaronfranke]

bash is always in /bin on a linux system, also on OS X.

Many Linux distros store it in /usr/bin instead, along with everything else that usually goes in /bin.

[hasufell]

Steam doesn't do that, and likely never will. Steam isn't a real package manager.

You missed the point. It isn't actually that hard for a program to keep track of all the files it will output in a given directory. Even programs on windows are able to do that sort of thing. No one said steam should become a package manager. It should just be able to clean up after itself and while it is updating.

[hasufell]

Steam doesn't do that, and likely never will. Steam isn't a real package manager.

You missed the point. It isn't actually that hard for a program to keep track of all the files it will output in a given directory. Even programs on windows are able to do that sort of thing. No one said steam should become a package manager. It should just be able to clean up after itself and while it is updating.

[craig-sanders]

@aaronfranke really? name these "many distros". in fact, name one. bash has been in /bin on linux forever because that's where system-native shells belong. third-party shells tend to go in /usr/local/bin. or in some bizarre location like /usr/opt/local/where/the/fuck/is/it on solaris.

@hasufell no, i didn't miss your point. you missed mine, which is that wasting time complaining about the fact that steam isn't a real package manager and doesn't behave like one is completely pointless and useless. Deal with things as they are, not as they should be and not as you wish they were. Steam is what it is, and there's a limit to what and how much can be fixed or improved.

[craig-sanders]

@aaronfranke really? name these "many distros". in fact, name one. bash has been in /bin on linux forever because that's where system-native shells belong. third-party shells tend to go in /usr/local/bin. or in some bizarre location like /usr/opt/local/where/the/fuck/is/it on solaris.

@hasufell no, i didn't miss your point. you missed mine, which is that wasting time complaining about the fact that steam isn't a real package manager and doesn't behave like one is completely pointless and useless. Deal with things as they are, not as they should be and not as you wish they were. Steam is what it is, and there's a limit to what and how much can be fixed or improved.

[hasufell]

which is that wasting time complaining about the fact that steam isn't a real package manager and doesn't behave like one is completely pointless and useless.

No, that's not what I said. Package managers are orthogonal to the point I made, which suggests you actually didn't understand the point.

Deal with things as they are, not as they should be and not as you wish they were. Steam is what it is, and there's a limit to what and how much can be fixed or improved.

That is just wild guessing. Why would it not be possible to fix the behavior as explained? I don't see any technical limit there. Please explain what "limit" that would be.

[hasufell]

which is that wasting time complaining about the fact that steam isn't a real package manager and doesn't behave like one is completely pointless and useless.

No, that's not what I said. Package managers are orthogonal to the point I made, which suggests you actually didn't understand the point.

Deal with things as they are, not as they should be and not as you wish they were. Steam is what it is, and there's a limit to what and how much can be fixed or improved.

That is just wild guessing. Why would it not be possible to fix the behavior as explained? I don't see any technical limit there. Please explain what "limit" that would be.

[craig-sanders]

you may think you were making some significant point, but really you were just wishing that steam was a real package manager. It isn't, and no amount of bitching about it is ever going to get Valve to devote the time and resources to make it one. There's little or no benefit to them in doing so - steam mostly functions well enough at what it is, a games library manager.

as for your "wild guessing" comment and request for an explanation of the limit - we're talking here about the steam.sh shell script, which is a wrapper around the steam application, doing environment setup and other things (like helpfully deleting all user files on certain error conditions). Rewriting the steam app so that it acts like a package manager should is way beyond the scope of fixing the obvious errors in a shell script. I would have thought that was obvious.

In case you hadn't noticed, Valve don't even acknowledge the fact that their crappy steam.sh script is still broken and puts user files at risk - there's some small hope that they might eventually do that and adopt some of the ideas and suggestions in this thread (there's some evidence they've already done that for some things), but there's no way they'll ever re-write the steam app to incorporate the basic features of a package manager.

[craig-sanders]

you may think you were making some significant point, but really you were just wishing that steam was a real package manager. It isn't, and no amount of bitching about it is ever going to get Valve to devote the time and resources to make it one. There's little or no benefit to them in doing so - steam mostly functions well enough at what it is, a games library manager.

as for your "wild guessing" comment and request for an explanation of the limit - we're talking here about the steam.sh shell script, which is a wrapper around the steam application, doing environment setup and other things (like helpfully deleting all user files on certain error conditions). Rewriting the steam app so that it acts like a package manager should is way beyond the scope of fixing the obvious errors in a shell script. I would have thought that was obvious.

In case you hadn't noticed, Valve don't even acknowledge the fact that their crappy steam.sh script is still broken and puts user files at risk - there's some small hope that they might eventually do that and adopt some of the ideas and suggestions in this thread (there's some evidence they've already done that for some things), but there's no way they'll ever re-write the steam app to incorporate the basic features of a package manager.

[hasufell]

you may think you were making some significant point, but really you were just wishing that steam was a real package manager

Again, no.

as for your "wild guessing" comment and request for an explanation of the limit - we're talking here about the steam.sh shell script

No, we are talking about steam as a whole.

Rewriting the steam app so that it acts like a package manager should is way beyond the scope of fixing the obvious errors in a shell script. I would have thought that was obvious.

Again, no. This is not about package managers. You seem to have no understanding of how the proposed technology works.

This is not about fixing half-assed shell scripts, which are already by concept wrong. This is about correctness, which is crucial when you deal with user files. Recursive deletion is never correct from an automated cleanup POV. Recursive deletion is something a user may trigger, based on his needs.

but there's no way they'll ever re-write the steam app

First, there is no rewriting of the "steam app" involved. Second, that's guessing again.

[hasufell]

you may think you were making some significant point, but really you were just wishing that steam was a real package manager

Again, no.

as for your "wild guessing" comment and request for an explanation of the limit - we're talking here about the steam.sh shell script

No, we are talking about steam as a whole.

Rewriting the steam app so that it acts like a package manager should is way beyond the scope of fixing the obvious errors in a shell script. I would have thought that was obvious.

Again, no. This is not about package managers. You seem to have no understanding of how the proposed technology works.

This is not about fixing half-assed shell scripts, which are already by concept wrong. This is about correctness, which is crucial when you deal with user files. Recursive deletion is never correct from an automated cleanup POV. Recursive deletion is something a user may trigger, based on his needs.

but there's no way they'll ever re-write the steam app

First, there is no rewriting of the "steam app" involved. Second, that's guessing again.

[aaronfranke]

@craig-sanders

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Solaris started it, Fedora was one of the first Linux distros to do it.

[aaronfranke]

@craig-sanders

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Solaris started it, Fedora was one of the first Linux distros to do it.

[mittwinter]

@aaronfranke really? name these "many distros". in fact, name one. bash has been in /bin on linux forever because that's where system-native shells belong. third-party shells tend to go in /usr/local/bin. or in some bizarre location like /usr/opt/local/where/the/fuck/is/it on solaris.

@craig-sanders: Sorry to barge in, but maybe you have to update your knowledge on this one:

• Fedora: /usr/bin/bash (https://koji.fedoraproject.org/koji/rpminfo?rpmID=11161824)
• ArchLinux: usr/bin/bash (https://www.archlinux.org/packages/core/x86_64/bash/)

And probably others already, as this merge of /bin to /usr/bin was advocated by systemd, so probably many other distros that switched to systemd will eventually follow.

[mittwinter]

@aaronfranke really? name these "many distros". in fact, name one. bash has been in /bin on linux forever because that's where system-native shells belong. third-party shells tend to go in /usr/local/bin. or in some bizarre location like /usr/opt/local/where/the/fuck/is/it on solaris.

@craig-sanders: Sorry to barge in, but maybe you have to update your knowledge on this one:

• Fedora: /usr/bin/bash (https://koji.fedoraproject.org/koji/rpminfo?rpmID=11161824)
• ArchLinux: usr/bin/bash (https://www.archlinux.org/packages/core/x86_64/bash/)

And probably others already, as this merge of /bin to /usr/bin was advocated by systemd, so probably many other distros that switched to systemd will eventually follow.

[dsohler]

No big deal since the merge to /usr/bin is done slowly and places symlinks for maintaining backwards compatibility.

So using /bin/bash is safe on “traditional” systems as well as on nowadays systems.

[dsohler]

No big deal since the merge to /usr/bin is done slowly and places symlinks for maintaining backwards compatibility.

So using /bin/bash is safe on “traditional” systems as well as on nowadays systems.

[ju2wheels]

Guys, we are bike shedding solving a problem which has already had a suitable solution presented and alternatives. Discussing it ad nauseam isnt going to make Valve come out and fix it if they have no interest, we have suitably voiced opinion here. Lets post a link to some other forum (Reddit, Google groups, or elsewhere) and take the sidebar discussion there.

[ju2wheels]

Guys, we are bike shedding solving a problem which has already had a suitable solution presented and alternatives. Discussing it ad nauseam isnt going to make Valve come out and fix it if they have no interest, we have suitably voiced opinion here. Lets post a link to some other forum (Reddit, Google groups, or elsewhere) and take the sidebar discussion there.

[mittwinter]

No big deal since the merge to /usr/bin is done slowly and places symlinks for maintaining backwards compatibility.
So using /bin/bash is safe on “traditional” systems as well as on nowadays systems.

This may be true so far, but every backwards compatibility will eventually be going away.
And this:

#!/usr/bin/env bash. bash is always in /bin on a linux system, also on OS X. and using env to find a script interpreter is brain-damaged.

is certainly outdated advice for any software maintained currently or in the future. Distributions will have to do enough patching for legacy software once such backwards compatibility is faded out.

[mittwinter]

No big deal since the merge to /usr/bin is done slowly and places symlinks for maintaining backwards compatibility.
So using /bin/bash is safe on “traditional” systems as well as on nowadays systems.

This may be true so far, but every backwards compatibility will eventually be going away.
And this:

#!/usr/bin/env bash. bash is always in /bin on a linux system, also on OS X. and using env to find a script interpreter is brain-damaged.

is certainly outdated advice for any software maintained currently or in the future. Distributions will have to do enough patching for legacy software once such backwards compatibility is faded out.

[polkovnikov-ph]

@ju2wheels But a Half Life 3 talk didn't even have a chance to start!

[polkovnikov-ph]

@ju2wheels But a Half Life 3 talk didn't even have a chance to start!

[user15177]

Has this problem been fixed? I really want to play the metro series, but this scares the crap out of me.

[user15177]

Has this problem been fixed? I really want to play the metro series, but this scares the crap out of me.

[dsohler]

@user15177 Set up a chroot for Steam and run it from there so it can do no harm to your actual system.

[dsohler]

@user15177 Set up a chroot for Steam and run it from there so it can do no harm to your actual system.

[alphapapa]

@craig-sanders Since you posted some cleaned-up code from the script and some good Bash scripting advice, a note: Always use the [[ ]] test syntax in Bash-specific scripts. It's safer and cleaner in all cases.

[alphapapa]

@craig-sanders Since you posted some cleaned-up code from the script and some good Bash scripting advice, a note: Always use the [[ ]] test syntax in Bash-specific scripts. It's safer and cleaner in all cases.