Update: Here is my current corrected version (do not trust blindly, I had typos involved too!)
#!/usr/bin/env bash
TEMPDIR="$(mktemp -d)"
mkdir --verbose -- "${TEMPDIR}/tests"
trap 'cd -- "${TEMPDIR}/tests" && rm --verbose --one-file-system -rf "${TEMPDIR:-/invalid/615e1a5d}/tests"; cd ..; rmdir --verbose -- "${TEMPDIR}"' EXIT
And an alternative variant in case there are only files without subdirectories involved under "tests":
trap 'cd -- "${TEMPDIR}/tests" && rm --verbose --one-file-system -f -- "${TEMPDIR:-/invalid/615e1a5d}/tests/"*; cd ..; rmdir --verbose -- tests "${TEMPDIR}"' EXIT
Note, I use --verbose to explicitly list files, because this is for my Test system. If you copy this construct to use in your own normal scripts, you might want to remove the verbose flags for normal usage.
Down below is old version:
This is just a little small question if this is secure. This script is used to create a fresh test environment that should get deleted when script ends. trap command solves that issue fine. 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). So I will do this in multiple steps.
#!/usr/bin/env bash
TEMPDIR="$(mktemp -d)"
mkdir -f -- "${TEMPDIR}/tests"
trap 'cd -- "${TEMPDIR}/tests" && rm -rf tests && cd .. && rmdir -- ${TEMPDIR}' EXIT
# Here follows the script content, creating temporary files and manipulating them...
- Use a subdirectory, so the variable is not used by itself. So we have to use
${TEMPDIR}/testseach time instead just${TEMPDIR}. - When removing all files recursively, first enter into directory with
cd, and only if that was successful delete all files recursively with a specific directory name. This should make sure thatrm -rfis only executed if the temporary directory even exist and the variable is not resolved to empty. - Off course go up one dir again and then remove the empty directory with
rmdir, which will only remove empty directories.
I personally feel confident that this construct is safe, but would like to hear your opinions. Maybe I missed something important. It would be devastating. I don't want to try out various ways to see if one of them is working correctly.
Edit: For anyone who does not create uncontrolled temporary directories, they could just use rm -f tests/* instead, so nothing is deleted recursively. I may go that route and avoid sub-directories in my test folder.
With Bash, you'll only ever get "good enough" solutions. Even with your current setup, it's susceptible to a race condition where another process adds to the
TEMPDIRdirectory some other way during the script, and potentially even recreatestestsafter you delete it and before you remove the parent directory.Usually with Bash, the most readable solution is the best. I'd recommend a simple test for
$TEMPDIRexisting before a simplerm -rf "$TEMPDIR".In this case, just test for this? Test that the variable is not empty and that the directory exists, then
rm -rfthe directory. No need to overcomplicate it.You mean a subprocess from this script? In that case, the variable
$TEMPDIRis never changed from the perspective of the script. Because its not exposed to subprocesses and the name is totally random bymktemp. So I don't see how a subprocess should be able to do that.This is what I want to avoid. Because what if I make mistakes in my own script and reassign
$TEMPDIRby accident in a loop, instead reading from it. So at the time of execution ofrm -rf, there is a chance that$TEMPDIRcould potentially point to a different directory in example.I'm referring to any process being able to do that, subprocess or not. If you know that no process on the system can interfere with your directory in any way, then you can be confident that nothing else will touch it.
Create another variable for use in the script, and only use
$TEMPDIRfor creating and deleting the directory then. As long as you are certain you don't reassign it, then you know the value won't change, and you can use a second variable to ensure you don't do that by accident.But how should any process know the variable of my script?
mktempmakes sure its 100% random. And any process on the system can't just read the variable out.Processes can touch any directory they have access to. There can be any number of reasons that a process might do this, from antivirus software (which somehow exists on Linux) to search software leaving index files everywhere to something that just for some reason modifies random directories. My point was that Bash can't guarantee that none of this ever happens, though
rm -rf "$TEMPDIR"would get around that and delete the directory anyway (and any lingering contents).Since you only seem to be worried about accidentally deleting the wrong directory due to mistakes while presumably debugging, this isn't really as relevant as I was suspecting it was. For something more robust though, I'd normally recommend a recursive delete without following any links (in case something links to files you don't want to delete, like
~or something).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 runningrm -rfcommand. 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.