On Thu, May 6, 2021 at 10:32 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > > On Fri, May 7, 2021 at 1:01 AM Elijah Newren <newren@xxxxxxxxx> wrote: > > On Thu, May 6, 2021 at 9:27 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > > > Is this expensive/slow loop needed because you'd otherwise run afoul > > > of command-line length limits on some platforms if you tried creating > > > the entire mess of directories with a single `mkdir -p`? > > > > The whole point is creating a path long enough that it runs afoul of > > limits, yes. > > > > If we had an alternative way to check whether dir.c actually recursed > > into a directory, then I could dispense with this and just have a > > single directory (and it could be named a single character long for > > that matter too), but I don't know of a good way to do that. (Some > > possiibilities I considered along that route are mentioned at > > https://lore.kernel.org/git/CABPp-BF3e+MWQAGb6ER7d5jqjcV=kYqQ2stM_oDyaqvonPPPSw@xxxxxxxxxxxxxx/) > > Thanks, I read that exchange (of course) immediately after sending the > above question. > > > > > + while test ! -f directory-random-file.txt; do > > > > + name=$(ls -d directory*) && > > > > + mv $name/* . && > > > > + rmdir $name > > > > + done > > > > > > Shouldn't this cleanup loop be under the control of > > > test_when_finished() to ensure it is invoked regardless of how the > > > test exits? > > > > I thought about that, but if the test fails, it seems nicer to leave > > everything behind so it can be inspected. It's similar to test_done, > > which will only delete the $TRASH_DIRECTORY if all the tests passed. > > So no, I don't think this should be under the control of > > test_when_finished. > > I may be confused, but I'm not following this reasoning. If you're > using `-i` to debug a failure within the test, then the > test_when_finished() cleanup actions won't be triggered anyhow > (they're suppressed by `-i`), so everything will be left behind as > desired. I didn't know that about --immediate. It's good to know. However, not all debugging is done with -i; someone can also just run the testsuite expecting everything to pass, see a failure, and then decide to go look around (and then maybe re-run with -i if the initial looking around isn't clear). I do that every once in a while. > The problem with not placing this under control of > test_when_finished() is that, if something in the test proper does > break, after the "test failed" message, you'll get the undesirable > alpine-linux-musl behavior you explained in your earlier email where > test_done() bombs out. Unless I'm misunderstanding the test_done() code (I'm looking at test-lib.sh, lines 1149-1183), test_done() only bombs out when it tries to "rm -rf $TRASH_DIRECTORY", and it only runs that command if there are 0 test failures (see test-lib.sh, lines 1149-1183). So, if something in the test proper does break, that by itself will prevent test_done() from bombing out.
