Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes:
> Makes sense. FWIW, the test *did* restore the CWD so things worked, and
> subshells are actually ugly (need to import test-lib-functions.sh again
> if you want to use those), but I'll make it work somehow.
You do not need to dot-include test-lib-functions or anything ugly
or special. The variables (not only the exported ones but regular
shell variables) and shell functions that is visible immediately
before you enter the opening "(" are all visible in the subshell.
The only notable difference you need to keep in mind when using
subshell is that you cannot affect variables and environment in
general of the calling shell. In this case, you are taking
advantage of it---no matter where you chdir to, the main test
procedure that spawned the subshell will not be affected even if
your tests fail inside a subshell. But it also disallows you from
doing certain things that rely on the ability to modify shell
variables, like setting up test_when_finished clean-up routine.
> More importantly, how do you feel about the "cd /"?
Please don't. If somebody had a repository in /.git and the program
you are testing is buggy, you'd risk destroying it. In general, it
is not a good idea to step outside the test directory you are given,
especially if you are *not* limiting yourself to read-only operation.
> The tests are always run in a place where there's a parent git folder
> (even if it's git itself), so you cannot reproduce the segfault in a
> test without the "cd /"
There is a "nongit" test helper in the test suite. Would that work
for your case?
Thanks.
