Description
If you run the tests like this, from the LIFE directory rather than the testing directory (the README is unclear about this):
$ git clone [email protected]:joconnor22/LIFE.git
Cloning into 'LIFE'...
remote: Enumerating objects: 144, done.
remote: Counting objects: 100% (70/70), done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 144 (delta 45), reused 36 (delta 36), pack-reused 74
Receiving objects: 100% (144/144), 89.68 KiB | 553.00 KiB/s, done.
Resolving deltas: 100% (68/68), done.
$ cd LIFE
$ testing/store-ref-data.sh
Storing new * RefData!
cp: ../examples/*/params.h: No such file or directory
$ ls -a
* . .. .git .gitignore
it deletes everything in the LIFE directory! This could be quite "irritating" if you happened to have uncommitted changes that could not be recovered from .git! (This just happened to me, and I luckily had a backup from yesterday, so could recover everything.)
The problem, as usual, is that bash is a terribly unsafe language. Adding some debug code, we see
$ testing/store-ref-data.sh
+ for d in '../examples/*/'
+ casePath='../examples/*'
+ caseName='*'
+ printf '\nStoring new * RefData!\n\n'
Storing new * RefData!
+ echo 'rm -rf *'
rm -rf *
+ echo Exiting
Exiting
+ exit 0
Since '../examples/*/' doesn't match anything, since we are in the wrong directory, bash returns it unevaluated, and a lucky sequence of path manipulations converts this into rm -rf *. At least it doesn't delete anything outside LIFE! The (weird) behaviour of bash can be fixed by using
shopt -s nullglob
so that the empty wildcard expansion expands to a null string, rather than to itself. See here. The loop is then never run, and nothing is deleted.
It would also be good to have an initial check for being in the correct directory so that the user is given a good error message.
I will make a PR.
Activity