# 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)"
[...]
# Scary!
rm -rf "$STEAMROOT/"*
The programmer knew the danger and did nothing but write the "Scary!" comment. Sad, but all-too-familiar.
Yikes. That should never have passed a code review. I know mistakes happen, I often defend screw-ups, but anything in a shell script that has an "rm" command should automatically get the squinty eyes.
I worked at a solar SCADA company that rolled there own APT packages.
In the pre and post install deb package scripts there was all kinds of crazy shit, like upgrading grub to grub 2 and manually messing with boot sectors. All this stuff in packages innocuously named modbus_driver.deb or what have you, and all in absolutely the most archaic bash syntax possible. I did suggest, strongly to jail all application binarys that we twiddle around with, with something like chroot, but was rebuffed.
Eventually somebody mixed a rm -rf /bin/* with rm -rf / bin/*, and the rest is history. They bricked about 100 embedded PC's, all in remote locations, all powering powerplant SCADA systems that did stuff like connect to CalISO for grid management or collect billing information. It cost hundreds of thousand of dollars to fix.
"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.
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:
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.
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.
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.
I worked at a solar SCADA company that rolled there own APT packages.
In the pre and post install deb package scripts there was all kinds of crazy shit, like upgrading grub to grub 2 and manually messing with boot sectors. All this stuff in packages innocuously named modbus_driver.deb or what have you, and all in absolutely the most archaic bash syntax possible.
Eventually somebody mixed a rm -rf /bin/* with rm -rf / bin/*, and the rest is history. They bricked about 100 embedded PC's, all in remote locations, all powering powerplant SCADA systems that did stuff like connect to CalISO for grid management or collect billing information. It cost hundreds of thousand of dollars to fix.
Whenever I write something scary like that, I usually wrap it in a function, double checking if it's really the folder you wish to delete ... Often even adding a user-verification if possible.
Since the script is written in bash they could also have used $BASH_SOURCE, which will always point to the correct path of the script being executed, so you can do something like this:
That's normal, but why the trailing slash?! That's just pointless, and almost looks like an explicit deathtrap.
Without the slash, an empty variable would result in a command line of "rf -rf" which would simply fail due to the missing argument.
There is absolutely no need for having a trailing slash, it's not as if "rf -rf foo" and "rm -rf foo/" can ever mean two different things, there can be only one "foo" in the file system after all.
Very interesting way of introducing an epic fail with a single character, that really looks harmless.
I have observed that ,any people feel that directories “need” to have a slash appended to them. They are afraid of ever doing, e.g. “cd /foo/bar” and will always do “cd /foo/bar/”. I”m guessing they feel like it would be some sort of type error, like treating a directory like a file or something.
This behavior is especially common with regards to URLs; there are many flamewars about whether URLs “need” a trailing slash or not.
The trailing /* is to delete the directory _contents_ rather than the dir itself. It would be safer to receate the dir as then you can possibly hit some of the inbuilt rm protections
But why would the script prompt for user input unless something was awry? Presumably they control the contents of $STEAMROOT, so I don't see why rm -r should prompt unless it's about to do the wrong thing.
The "rm -i" alias is a horrible, horrible idea. Red Hat has a lot of stupid defaults, but this is probably the most questionable one.
The useless confirmations on every deletion is so intrusive that people will instinctively try to work around it. In the best case they'll undefine those crappy aliases in their own shell config, or maybe gravitate toward writing /bin/rm rather than rm to avoid the alias expansion. In the bad case they'll learn that "rm -f" will override "rm -i", and get in the habit of using that to shut rm up. Too bad that "-f" does more than negate "-i"...
People who don't actively work to circumvent the braindamage will almost certainly end up reflexively teaching themselves to just answer "y" to the prompts without reading. Or worse, they'll learn to depend on the prompts being there, and doing "rm * " when their intent is not to remove everything. "Yeah, I'll just answer 'n' for the files I want to keep". That's going to be a really nasty surprise when they use a machine without that alias.
No. Just no. Don't do it.
The solution in zsh is much better. Warn for "rm * " (or "rm * .o", etc) no matter what, since that's both very dangerous and very rare. But don't waste the user's attention on every single deletion.
Hmm. Well I guess it's just me then. I've been burned so many times by rm/mv/cp that I actually do always read their confirmations and give it a 2nd thought. I rarely delete files unless it's a mass delete or files & folders that I do "rm -rf". and I pretty much never intend for mv or cp to overwrite an existing file.
zsh has a nice feature where rm is only interactive if you are deleting everything in a folder. Another safety feature I really like in zsh is to tab-expand wildcards, so I can check that it's not deleting anything it shouldn't.
Frankly put, it's a fantastic development environment -- mostly because it's targeted at developers/power-users and not the average user.
It has the added benefit of being inside the "RHEL/CentOS" ecosystem (similar commands, structure, etc), provides a glimpse of what's-to-come in future releases of RHEL/CentOS, and since majority of servers in the enterprise are RHEL/CentOS based, it's a natural fit.
All that aside -- have you tried Fedora 21? It's a complete overhaul from previous Fedora releases and has a lot to like and offer.
I guess I have always had ideological issues with RedHat, as a distribution. It doesn't surprise me that they would put the -i alias in Fedora; this kind of "helpful" addition that is actually totally annoying and inappropriate is, IMO, emblematic of the distro.
Anyone considering putting customization like aliases where they'll execute even for non-interactive shells should go home and rethink their life. Thankfully, I've never encountered such a system.
If all one is in the habit of using with a particular command is some single letter flags glommed together like that then it's possible to forget that they're actually separate flags.
