Jeff King <peff@xxxxxxxx> writes: > Is this right place to do it? > > It doesn't catch "cd t && make".... That's just an illustration. I know my audiences who will give us real tested patches are intelligent ;-). And I tend to agree that at the test-lib.sh level might be a bit too low for convenience of debugging, but it is probably a good start. An obvious alternative would be a patch similar to the illustration patch applied to t/Makefile. As I said in a separate post, I think this is orthogonal to the test-terminal patch under discussion. Being able to give the tested programs an environment that mimics an interactive tty session better is a good thing to do regardless of the "test should not read from make's stdin" issue. > happen in t/Makefile. But I actually wonder if it should be in > test-lib.sh, as it is as much about cleaning up the test script's > environment as it is about protecting people running "make test" in a > loop. I.e., something like: > > diff --git a/t/test-lib.sh b/t/test-lib.sh > index bdd9513..5a38505 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -198,6 +198,9 @@ else > exec 4>/dev/null 3>/dev/null > fi > > +exec 6<&0 > +exec 0</dev/null > + > test_failure=0 > test_count=0 > test_fixed=0 > > One downside of that approach is that it makes it harder to insert > questionable debugging statements into test scripts. E.g., sometimes I > will temporarily throw a "gdb" or even a "bash" invocation into a test > script to investigate a failure. But that would still be possible by > redirecting from "<6". > > -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html