[colanderman]

Not if the previous line was:

    STEAMROOT=$SOME_OTHER_UNSET_VARIABLE/

"rm -r " is a code smell, as much as "cc -o myprog .c" is. You should always know what files make up your system, and track them in a MANIFEST file. There's rarely a good reason to use wildcards when a program is dealing with its own files.

    xargs rm -df -- < MANIFEST

fixes this.

[__david__]

That looks like it works until your MANIFEST file ends up with a space character in one of the file names.

For GNU xargs I like adding -d\\n which handles everything except files with an embedded newline. Those are much rarer than files with a space, though.

Sadly, OS X xargs (probably BSD based) doesn't have that option, so I have an alias to do the same thing:

    alias xargsn="tr '\n' '\0' | xargs -0"

[colanderman]

Good catch.

[jblow]

Steam doesn't deal with its own files. It deals mainly with random games that are creating tons of random files.

[mercurial]

Doesn't it have an API? It could mandate that "random files" should only be created and deleted via the API, and update the manifest accordingly. Put the game in a read-only folder to make sure it happens.

[vertex-four]

Steam actually sells a number of games which haven't been modified for use with Steam at all - no DRM integration, no achievements. Further to that, it sells games which use closed engines that are never going to be modified to use Steam's APIs to do things.

[hobs]

Or worse, basically just glorified installers for games for windows live, or ubisoft's giant portal thing that you have to then run simultaneously (or in the right order) to get to the game.

Its definitely a rube goldberg machine in action.

I feel like the idea of sandboxing its progeny is going to need to look like docker or some sort of container where it appears to be a standard OS (since games use a lot of low level hacks) but is actually partitioned from the rest of the system.

[falcolas]

   rm --preserve-root

isn't a bad thing to have either. That way, even if you do screw up, you won't be able to run rm against '/', even with '-f'.

It's one of the top aliases in my .bash_aliases file.

[colanderman]

Agreed. Thankfully this is the default on many systems (I'm guessing recent coreutils).

Unfortunately dumb lines like "rm -rf $HOME/$STEAMDIR" still get through unscathed.

[philh]

I think that

    rm --preserve-root -rf /*

doesn't save you.

[colanderman]

You are quite correct.

[Zikes]

What if you somehow wound up with a single line of / in the MANIFEST, though?

[colanderman]

"rm -df /" does nothing. "rm -df" does not remove non-empty directories.

[Zikes]

That's awesome, I didn't catch the s/r/d/.

[colanderman]

That's because I ninja'd the -d in after ;) also just ninja'd in a -- to prevent stray options.

Note also that putting a "*" in the MANIFEST doesn't do anything either, as neither xargs nor rm expands wildcards (only bash does).

[Hello71]

    rm: cannot remove ‘/’: Is a directory

[8_hours_ago]

Fyi: the -d option is specific to the BSD implementation of rm, it's not available in the GNU coreutils rm.

[colanderman]

It's in my coreutils (8.22). Maybe it's recently added?

[8_hours_ago]

It looks like it was added in version 8.19. Probably about time to update my Ubuntu box...

http://savannah.gnu.org/forum/forum.php?forum_id=7342