• 0 Posts
  • 26 Comments
Joined 9 months ago
cake
Cake day: December 28th, 2025

help-circle


  • But you’re still deleting files with recursion, despite saying

    I would always prefer deleting files without recursion and then deleting empty directories. Why is that moot? The point is not to use recursion.

    So if you’re using recursion to begin with, rm -rf "$TEMPDIR" is simpler than your rm -rf "$TEMPDIR/tests" && rmdir $TEMPDIR, and works identically except for when $TEMPDIR has other files. But it doesn’t sound like that’s the case.

    If you’re always opposed to using recursion, why are you ok with using it to remove the subdirectory?



  • I generally dislike using the set methods to change how the “language” works. So even if it covers my issue, I’m not using it.

    If you don’t feel like using it, that’s valid, just as long as you’re aware of the functionality. It seemed fitting here to me because of the potential to simplify the code from a complex chain of commands with hard-coded values to a single command with no hard-coding, while keeping the old behavior.

    Also if cd -> rm -rf -> rmdir solves it, why would I need to rewrite and change it to set -u -> rm -rf?

    You don’t. You asked for feedback, though, so I gave some.

    In general, I’m a fan of set -u because it helps to avoid some common scripting bugs, but if you’re aware of the option and how it could be used, and you choose not to use it, then I’m not going to insist you write it how I would write it.



  • However, I am very, very afraid of doing rm -rf in context of variables, in case the variable happens to become empty due to user error (or later changes in script).

    I get the feeling that either there’s some missing info, a misunderstanding on my part, or there might be a simpler way to do things. Is $TEMPDIR changing a reasonable case to handle? Can you change your script design to make this impossible instead? (Like replacing a source with a script execution?)

    If the snippet is just boilerplate at the top of numerous scripts, I’d do set -u, rm -rf "${TEMPDIR}" on exit (ideally defined in a common setup script/function), and just avoid assigning to the var later in the script. In terms of defensive programming, anything extra is added complexity that will only make an error more likely imo. You could rename TEMPDIR to something like TEST_ROOT if you’re concerned about the variable name being accidentally used again, but no amount of trap logic is going to make a future programming error impossible.






  • Slow depends on the use case. If your main bottlenecks are in code that people have written highly optimized lower-level libraries for, it could be slower to roll your own implementation or use a less mature library in a different language. And in some cases it might not matter if you take 1 ms or 100 ms to do something.

    It works the other way too, and you have to weigh the pros and cons of your specific case when you choose a language. What level of abstraction do you want to work at, how stable do you need the toolchain to be, how familiar you are with the language, what’s supported in the language, how easy is it to do what you want, what’s the norm in the domain you’re working in, etc.




  • Canonical’s hiring process is wild. The number of stages is a deal breaker in itself, but the bizarre questions and the tests you mentioned don’t do them any favors either.

    I lost interest in the first stage with them asking for an essay about things like what kind of student I was in high school. The full email was massive.




  • I don’t think this paints all of atheism as a bad thing, just satirizes militant atheists who struggle with the fact that others can peacefully hold beliefs that are incompatible with their own. Reddit’s full of them, and they’re the equivalent of the evangelizing Christian that jumps on the “you need Jesus” spiel at the first whiff of non-Christian views.

    In my (atheist) opinion, the two are equally obnoxious.