John Keeping <j...@keeping.me.uk> writes: > All are harmless at the moment and t7610 and t5801 can be fixed by > moving the test_when_finished call out of the subshell relatively > easily. > > t7800 (in its final test) calls test_config in a subshell which has cd'd > into a submodule. > > Is this something worth worrying about, or is it sufficiently rare that > we can live with the current behaviour?
Fixing the instances you found is good, obviously ;-). Thanks for working on this. Even though the proposed detection is BASH-ism, I think it would not hurt other shells (they obviously do not help you catch bugs, but they would not misbehave as long as you make sure BASH_SUBSHELL is either unset or set to 0 at the beginning of the test), and the only impact to them would be a invocation of (often built-in) 'test' utility, whose performance impact should be miniscule. I'll wait for opinion from others, of course. > > [0] http://article.gmane.org/gmane.comp.version-control.git/277199 > > -- >8 -- > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh > index e8d3c0f..d29cd7b 100644 > --- a/t/test-lib-functions.sh > +++ b/t/test-lib-functions.sh > @@ -722,6 +722,8 @@ test_seq () { > # what went wrong. > > test_when_finished () { > + test "${BASH_SUBSHELL-0}" = 0 || > + error "bug in test script: test_when_finished does nothing in a > subshell" > test_cleanup="{ $* > } && (exit \"\$eval_ret\"); eval_ret=\$?; $test_cleanup" > } -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
