That’s the point, I do not want to do rm -rf "$TEMPDIR", which is a variable only. Adding a fixed string like “/tests” makes sure that recursive deletion never operates on a variable only. That has the sideffect that the $TEMPDIR itself isn’t deleted, so I have to do it manually with rmdir.

I don’t use rm on a variable only, but with fixed path as $TEMPDIR/tests. Therefore the actual last empty $TEMPDIR needs to be deleted separately.

I do not think that one command is more secure, compared to multiple steps to make sure it is secure. It can be, but it can be worse too.

And the advantage of rmdir over rm -r is, that it only deletes empty directories, is safer in some usecases. But this is moot, if you delete it’s content anyway.

Why is it safer in only some cases? I would always prefer deleting files without recursion and then deleting empty directories. Why is that moot? The point is not to use recursion.

That’s an interesting way of doing it. I do not try to avoid rm completely, just want to make sure the construct doesn’t have any obvious issues. Your suggestion is a bit too much for the few test files I wanted to create and delete.

Looks interesting. There was even a sale for programming related games recently. So there are lot of interesting games for this genre. I personally do not have any specific recommendations, so any are welcome here.

Why do you think so? Changing directory can only be done, if it exists, otherwise cd will error out and rm command not run. After the command the temporary directory is empty and cd can go up one dir, to use rmdir on an empty directory. Which of the steps are fragile and why?

Funny enough I’m writing (and wrote before) a Python script that is all about files and renaming. And this Bash script is about creating a test environment. Maybe its actually a good idea to write this in Python too.

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. Its also not even said that these options couldn’t be changed, in fact I think in some cases it can be useful to change those options temporarily for certain effects like “pipefail” or the one that prints the executed lines. But not as a default or for critical commands that can run at any time the script exits (even on error). Maybe someone (even me) copy pastes this line in example.

I always forget which of these set options do what, and next time when I write or read another script it could have different set of options. So I ignore those set options to change how the language is interpreted in Bash. Also if cd -> rm -rf -> rmdir solves it, why would I need to rewrite and change it to set -u -> rm -rf?

I know, good habit, check variable and so on. But mistakes happen, so what’s wrong with hardening the case? There are decades of studies and good practice for coding, yet the best programmers still do mistakes. And having a script that could potentially delete files on your system (even all subdirectories) is dangerous and should be handled with respect. I really don’t understand the opposition here.

In terms of defensive programming, anything extra is added complexity that will only make an error more likely imo.

I disagree here. Adding checks will help in catching those errors. Being not defensive about it will make it only more likely to make errors.

no amount of trap logic is going to make a future programming error impossible.

No amount of any programming will make it impossible to error out. That does not mean we shouldn’t try to make it as secure as we can think. Renaming the variable is putting the risk to another name, not really solving the issue.

Did you even read man rm

That was an unnecessary snarky comment.

Maybe play a learning game. There are games that teach you programming. Either simple text based games, or maybe even full videogames with the topic of programming. This could arouse your appetite to actually learn it.

Well Ai isn’t a drug, so its totally up to you to stop using it. At least during the learning phase. If you have no control over yourself, but you really want to stop using it, then maybe you need to do some more drastic measures. In example uninstall any Ai software you have, put the webpages with the Ai bots you would use on a block list. I can’t give you a strong will, you have to build it yourself.

Ah I absolutely misunderstood you. The PID trick is actually clever!

But I would still not solely want to rely on a $TEMPDIR variable alone, without a fixed path like "${TEMPDIR}/tests". The reason is, I am not just concerned about the trap cleanup, but also the usage in the script. I want never use the variable in the script (after setting up trap) without a fixed path on it. In example the script will change filenames, eventually using glob patterns or do other stuff. If the script is faulty and changes the temporary variable, then it will at least do this under “tests” no matter what.

The idea is neat though. I have to think about this, experiment and see if I end up using this.

You said you would just use scripts and use Ai, instead learning:

use scripts and ai for everything and not learn anything

If you are not interested into learning, how do you want program? My suggestion is to stop using any Ai tool, do not run others scripts until you understand what they are doing, and start learning. Maybe start with something like Python. There is a lot of material, tutorials and good documentation, even good help on YouTube, and a huge and I mean a huge community who is willing to help you. If you use Ai during this period, I don’t think you will learn much. In worst case, you get very bad habits and learn not to think critically.

It would be good to know what you tried so far, what your interest is, if you have any ideas what you even want to program.

i dont program but if i did id proballey just use scripts and ai for everything and not learn anything

If you used pre-written scripts or vibed your Ai output without learning, then you wouldn’t be programming.

what do you do to motivate/stop yourself

To motivate myself to program? First, if its not fun, then I don’t do it. Just a hobby for me. Sometimes I need some motivation, and that is a) I did it myself, can be proud of, b) it might help others, c) to solve a real issue I have myself, d) programming is fun, just for the sake of, e) the prospect of learning something and be able to solve it myself, and it could help solving real issues later when needed, it happened even for work. Just some stuff I can think off in my head.

To stop to program? Well sometimes its time consuming without results, without finishing something. Even though I learn, it can feel waste of time. I could have done something else in this time. It’s just a hobby in most cases, so in most cases I compare programming to something like playing a game or watching a movie.

What about you? If you are not interested into programming, why are you posting in programming?

Edit: Please ignore this reply here, and read the discussion following the answers. I absolutely misunderstood the above reply.

mktemp --suffix=$$ does not really solve the issue I have. I don’t want to use ${TEMPDIR}, but have something hardcoded when using the variable, as in rm -rf "${TEMPDIR}" vs rm -rf "${TEMPDIR}/tests". Because I’m not worried about what mktemp gives me back, but about when the variable is used at later time. The content of the variable could be altered after its initial creation.

In your trap assert that the content of var TEMPDIR ends with your same current PID or fail before you clean anything up.

I quiet don’t understand this point here. The trap command will run in any case the script exits, be a crash or normal exit. If the variable or directory is invalid, then the cleanup will not be executed. But that is by design, because I do not want to cleanup something that is not working correctly. I rather leave it to be cleaned up automatically with next reboot.

You could also assert TEMPDIR is prefixed with $TMP or /tmp for even more robustness.

It has already a fixed suffix part with “/tests” in use. I’m not worried about the TEMPDIR content if mktemp created it correctly. I’m more worried about the variable being altered and invalid at later point in the script. I would rather leave mktemp create the directory where it thinks is the best place (mostly it is /tmp, but that is not guaranteed). So prefixing the variable content itself doesn’t really solve the trust issues I have here, as it is not the creation time that I’m worried about.

I actually have trash-cli installed and exclusively use it for deleting all trash directories available on my system. Because I experience some inconsistencies how applications handle trash directories, involving mounted external drives.

Moving files instead deleting them, in case they are important files is a good advice. However in case of temporary created and deleted files for testing software, I think this goes a bit too far. But it could prevent data loss, in case something goes wrong and I delete the wrong directory (hopefully the trash directory does not get deleted too, due to recursive deletion). Overall, this is a good advice to have in mind, I just think it goes a bit too far in this use case.

What if I would use /dev/null instead /invalid? Do you think this is a problem, better or worse? rm -rf ${TEMPDIR:-/dev/null}. I will update the current solution above, but need some research first. Edit: Oh wait, that could be dangerous if. If the script runs with root privileges, then /dev/null would be deleted.

My reply is rejecting (most of) your suggestions, with reasons off course. I am glad you bring them up, so we can talk about it.

I would avoid set -e option, as I do not want he entire script to exit on error. So instead I can use the exit command when I really want to on specific errors. I rather would like to handle errors myself directly, maybe even not exiting, but displaying error code with $? in example.

TEMPDIR=$(mktemp -d || echo "/invalid")

If anything, it would make more sense to just exit the script with || exit. In fact that is what I’m doing in the script after the trap command by cd "${TEMPDIR}/tests" || exit, so the script never continues without a successful mktemp directory.

TEMPDIR=${TEMPDIR:-"/invalid"}

I always forget that Bash has default values for variables! mktemp actually makes sure it never returns an empty value. I’m not worried about what it returns, but that my script could change the value of $TEMPDIR by accident (in example to something empty). So assigning a default value after mktemp will never have a chance to get the default value at all.

rm -rf ${TEMPDIR:-"/invalid"}

This on the other hand I like a lot. Now I will not stop doing my other additional checks, but for good habit this can’t be wrong. Maybe instead a custom directory name with an unlikely name, what about pointing it to /dev/null? I actually like this idea and might incorporate it.

In case any process deletes files or the directory “$TEMPDIR” points to, the script should be covered, right? With cd -- "${TEMPDIR}/tests" it is guaranteed that the directory exists when running rm -rf command. And in case the “$TEMPDIR” variable is altered in any way (replaced or added home, ~ or any relative paths like …/…/…/home in example), at least having a hardcoded directory name with “tests” would make sure it never deletes anything under any circumstances that is not named “tests”.

Unless symbolic links and other link files are involved and added to that directory.