Hacker News Reader

Comment by jjnoakes | Hacker News Reader

There's nothing wrong with that line as long as you know "$STEAMROOT" contains a directory that you wish to nuke.

The issue is that this particular script did not set up $STEAMROOT correctly.

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

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.

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.

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

If you want to blow away a directory, do this just to avoid wildcard games:

  rm -rf $the_dir && mkdir $the_dir

Yes, it's technically slower, but this is shell.

Should mkdir be first (so that it short circuits if $the_dir is unset?) I haven't done anything in bash in a while but that seems to be how it works on my computer (Debian Wheezy, bash 4.2.37).

The original broken code was using a wildcard to clear a directory. I proposed a safer way of doing that: delete the directory itself then recreate it.

Reply on news.ycombinator.com