Hacker News new | ask | show | jobs
by colanderman 4172 days ago
The thing is, there are so many ways for STEAMROOT not to be set correctly in Bash. Just one typo in some future edit can bork everything if it's not tested thoroughly.

Sure, you could somehow check that STEAMROOT is set to something resembling what you want to delete. But manifests are much more simple to get right.

EDIT: Alternatively, pick a well-known UUID, and put everything under a directory with that name under STEAMROOT. Then, to remove:

  rm --one-file-system -rf "$STEAMROOT/d0a8936d-1faf-4b82-aac9-e5f104432b24"
This won't do the wrong thing, as it will require that unique string to be present in the pathname. (--one-file-system for good measure.)

(Don't put the UUID in a variable, or you're back to square one of having a potential bug!)

3 comments

I'm always annoyed when I see UUIDs in my directory structure, it's the same feeling I get when I see a big mac wrapper littered in my yard, or MSOCache in Windows system root for that matter.
If you can't write a shell script without being sure your variables are set, then don't write it in shell.

A MANIFEST is not the right answer. Steam deals with any number of third-party games which may drop any number of files into these directories.

The best way to nuke a directory is 'rm -rf "$DIRECTORY"'. Any amount of "well what if $DIRECTORY points to the wrong place" has nothing to do with the removal operation itself.

How about using a better language? She'll scripting is an awful, awful language. An error like this wouldn't have happened if the program had been written in C or Python or Perl or whatever your choice might be.

Shell scripting seems tremendously overused. It makes some things a bit easier, but it's so crazy it makes PHP a look like a pinnacle of good language design.

Using C or Python or Perl does not automatically keep people from failing to check whether some code that reaches out into the environment to prepare for later action actually succeeded.
It tends to fail much more noisily if you try to use an uninitialized variable - C will probably segfault (or end up removing a garbage string of probably-unprintable characters), Python and Perl will throw exceptions.
I don't see any way to accidentally write code in C or Python (Perl may be a different beast as a sibling comment indicates) that deletes the user's home directory if an environment variable is unset. These languages don't keep you from failing to check, but they fail much better. An unset environment variable without a check means you'll probably crash, whereas with a shell script you just keep on going, with bad data.
I don't disagree with you. (Although Perl exhibits exactly the same issue.) Unfortunately bash is the lowest common denominator on Linux and is often chosen on that basis.