in the last 10 years if you been working you would likely have that much by now

This might be more likely for big tech workers, but it's less realistic the further you get from the Silicon Valley archetype. Saving millions over 10 years would mean averaging $200k+ per year after taxes and expenses, which I can't imagine will happen in my career unless I start a successful business or get lucky gambling on stocks.

STOP USING LINUX

• PIPES WERE NOT SUPPOSED TO BE GIVEN NAMES
• YEARS OF COMPUTING yet NO REAL-WORLD USE FOUND for going deeper than FILE EXPLORER
• Wanted to go higher anyway for a laugh? We had a tool for that: It was called "WINDOWS REGISTRY"
• "Yes please turn my FILE into a device. Please mount it as MANY files" - Statements dreamed up by the utterly Deranged

LOOK at what linux Developers have been demanding your Respect for all this time, with all the computers & mice we built for them

(These are REAL Scripts, done by REAL Developers):

• mkfifo pipe && f >pipe | g <pipe ?????
• mapfile -d '' -t fs < <(find . -print0) ???????
• :(){ :|:;};: ?????????????????

"Hello I would like $(perl -e 'print unpack C, qx|head -c1 /dev/urandom|') apples please"

They have played us for absolute fools

Then if you're wanting to only remove the directory if it has a tests subdir, the typical way would be to check [ -d "$TEMPDIR"/tests ] before recursively removing $TEMPDIR. No need for the cds or double remove.

I'm asking why, though. The "variable only" thing doesn't make sense. If you're worried about it being unset or not pointing to a directory, use test / [ with -n or -d. If you can't trust your own script to not change the variable, that's a hell of a threat model and you shouldn't remove anything.

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?

You're already deleting files recursively:

rm --verbose --one-file-system -rf "${TEMPDIR:-/invalid/615e1a5d}/tests"

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.

I think you mistook my asking questions as opposition, or maybe my intent wasn't clear enough in my comment. My main point was that while I don't have full context for the problem, it seems to me that a simpler solution exists. Is there some edge case that the cd -> rm -rf -> rmdir snippet covers that's missed by set -u -> rm -rf?

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.

I read through the page and I understand the problem better, but I still don't know what I could do differently as an occasional donator. I found this for helping with development, but I'd prefer to support with donations since I don't really have time for more dev work. Is there some way to donate directly for the operating costs, or to volunteers, or something?

100%, but to add a caveat on buying used, I've heard some people use cast iron pans for melting lead. Depending on who you buy from, you might want to test it before cooking with it, although I'm not familiar with how to test it or how common lead melting is/was.

There's a lot of folklore around cast iron, so be careful when taking advice on what to do. Please wash your pan even if people yell at you for doing it; it's hygienic and won't strip the pan unless you have soap with lye in it. If your soap does have lye, you'll probably want some that doesn't.

Also, don't feel like you need to coddle it. It's a big chunk of iron. It'll be fine despite people insisting you need to follow their way or your pan will explode. It can get weirdly cult-like. If you mess up too badly, you'll just need to strip the pan and put a new layer of seasoning on it, which isn't that difficult.

That said, you'll probably need to use more fat than you thought you'd need while cooking when you're building up the seasoning. Eventually, things will stop sticking as much, though.

If not them, who? I don't know of any project that comes close to Wikipedia, and as someone who doesn't know anything about their internal politics (although I'm open to learn), I feel like it would be a bigger tragedy if it went under. It seems to benefit from being independently funded instead of either being absorbed by some corporation with other motives, or being replaced by a product from some corporation.

One of the games of all time

You said they're called octets because they're supposed to be written in octal. I was saying why I don't think that's true.

That smells a little like folk etymology to me, are you sure about that? My understanding is that since the word is older than computers and can refer to any group of 8 things, "octet" in computing just came from the need to communicate a group of exactly 8 bits given that bytes aren't always that size.

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.

I took it more as a plea to people who think it's optional year round

I've had some not so good pig intestine and some phenomenal, and the worse ones were similar to how you described it. If you ever decide you'd try it again, I think it's so much better when crispy. The texture reminds me of bacon with a gelatinous, melt in your mouth center almost like burnt ends.

I wouldn't buy a whole thing from the store unless you know you like it, but if you like cilantro and jalapeno, a banh mi with head cheese and pate is a good way to try it. It's a delicious mix of fresh, savory, fluffy, crunchy, and chewy.