9

It turns out that using bash without "set -u" (without it, bash replaces every unset variable with an empty string, without error or warning), isn't such a great idea when you change your script later and you forgot to delete the following line:

rm -rf $OBJ_PATH/*

Comments
  • 2
    Oof

    EDIT: Wrong tag btw, devrant tag is for stuff about the devrant platform itself.
  • 1
    You get a big oof from me.
  • 1
  • 0
    ${OBJ_PATH:-${PWD}/obj} goes a long way too. I’ve made that mistake , so now I’m hyper critical of setting default values .
  • 0
    why is `-rf` still coupled with `rm`?

    1. alias rm='rm -i'

    2. rm -rv <whatever> ( note I replaced f with v )

    yes, when you're obliterating stuff, you better go through that annoyance otherwise it is not worth it.

    or else ( for the lazy ones ), use absolute paths. No variable expansion / substitution whatsoever.
  • 0
    It's most of the times not clever to rely on bash options.

    I don't know why people try to "cheat their way out by using options or doing any other shenanigans"....
  • 0
  • 0
    @IntrusionCM isn't that too far fetched when you're trying to run commands on a command line?

    but I agree, when you're running `rm` commands, you better slow down and take a good hard look before hitting 'Enter'.

    in the beginning of my career, my right pinky was the fastest finger. it would even miss last characters, overstep and hit <Enter> before the command was complete. Then I started ending commands with <space> or <Tab> to overcome that problem.

    It took me a similar destructive action to learn my lesson ( the hard way ) and slow down. didn't delete root, but `$HOME` though which was painful enough.

    Even now, the pinky is fast, but then I got both my pinkys fast enough so that the left one is on <shift> when hitting <Enter> unless I am completely conscious ( of the consequence of my action ) and lift the left pinky ( or even the whole wrist ) away.
  • 1
    @shine just that I get this right....

    You're defining variables in a running shell prompt (not script) and then use an rm -rf on a variable that you've defined some lines before...

    Oh boy.

    I'm a friend of opening a scratch file in IDE and instead of running commands line by line write them down in a shell script.

    Always.

    The reason I said oh boy before is that any program you ran can mess with your shell prompts environment - unless you use bash and constants, literally anything can gobble up whatever you defined in the prompt.

    Shell script / subshell - own environment - yes please.

    And in a command prompt, rm --interactive alias is definitely the right thing to do.

    Writing shell scripts might be slower, but a lesson I learned as admin is that seconds wasted with dumb error checks can mean hours of more sleep and sweet dreams instead of trying to recover from desaster in a night shift.
  • 0
    For the future, in addition to set -u, always define directory path variables with a / at the end and not add one later. this way, rm -rf $OBJ_DIR* will by replaced by rm -rf *, which is much less problematic. It only affects the project and the .git folder will still be there
  • 0
    @happygimp0 no, that's not the solution. the solution is to eliminate the use -f / --force.
  • 0
    -f is needed to ignore non-existing files.
Add Comment