41–50 of 280 posts
Note to all, prepend all your bash script with "set -o errexit -o nounset -o pipefail" It'll save you headaches.
Yep, my thought exactly. My standard bash header is #!/bin/bash set -eu IFS=$'\n\t' (Wish there was a shorthand version of pipefail, then I'd always use that too.)
# Scary! rm -rf "$STEAMROOT/"* Anybody who writes a line like this deserves their software engineer license revoked. This isn't the first time I've seen shit like this (I've seen it in scripts expected to be run as root, no less); it makes my blood boil. Seriously. "xargs rm -df -- EDIT: I shouldn't be so harsh, if it weren't for the comment admitting knowing how poor an idea this line is.
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.
rm -rf $the_dir && mkdir $the_dir
Note to all, prepend all your bash script with "set -o errexit -o nounset -o pipefail" It'll save you headaches.
To get the same effect as the "set -o errexit -o nounset", I think you can use "#!/bin/bash -e -u". (There seems to be no option for pipefail.)
What is this magic doing? $(cd "${0%/*}")
$0 is the path of the script. ${0%/* } takes $0, deletes the smallest substring matching /* from the right (the filename) and returns the rest, which would be the directory of the script. So this changes the directory to the directory the script is located in.
And yes, dirname is a way out of this. I'd do this:
"$(cd "$(dirname "$0")"; pwd)"
# Scary! rm -rf "$STEAMROOT/"* Anybody who writes a line like this deserves their software engineer license revoked. This isn't the first time I've seen shit like this (I've seen it in scripts expected to be run as root, no less); it makes my blood boil. Seriously. "xargs rm -df -- EDIT: I shouldn't be so harsh, if it weren't for the comment admitting knowing how poor an idea this line is.
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.
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"
(Don't put the UUID in a variable, or you're back to square one of having a potential bug!)
I don't want to blame anyone, but maybe there should be foolproof default security measures that prevent something like this from happening. For example rm -rf called on a home, documents, music, photos etc. directory could require an additional confirmation, perhaps through a GUI.
There are, it's called users, and groups, and file permissions. Applications like steam should really be running under a separate user so they can't write to personal files (and maybe just have read permissions). But of course proper application isolation and file permissions is something few people do correctly on their personal machines, let alone know about. Window managers don't make it any easier, and I put a lo…
Earlier quoted context omitted.
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 -- fixes this.
What if you somehow wound up with a single line of / in the MANIFEST, though?
rm: cannot remove ‘/’: Is a directoryEarlier quoted context omitted.
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 -- fixes this.
What if you somehow wound up with a single line of / in the MANIFEST, though?