On Fri, Aug 20, 2021 at 08:12:50AM -0400, Philippe Blain wrote: > Thanks everyone for sharing their input and concerns. I understand that the behaviour > change might not be wanted all the time, or by everyone. > > I also did not think about the implications of changing $HOME that could lead to the > test framework overwriting stuff in my home. I checked the tests and there are only > a handful of them that seem to reference HOME, but still, for those tests it would be > undesirable to reset HOME. > > In light of this I'm thinking of simply adding flags to 'test_pause' and 'debug' to signal > that one wants to use their original TERM, HOME and SHELL, with appropriate caveats in > the description of the functions: > > test_pause # original behaviour > test_pause -t # use USER_TERM > test_pause -s # use SHELL instead of TEST_SHELL_PATH > test_pause -h # use USER_HOME > > and combinations of these three. > > For 'debug', Carlo's idea of just symlinking/copying gdbinit and/or llldbinit to the test > HOME might be easier, and would cover the majority of developers, I think. As for TERM, > we could do 'debug -t' as above, or use USER_TERM always... > > I'll explore these ideas before sending v2. As an even more different alternative, what do you think about making it easier to break out of the test suite at a particular state? That would let you inspect it from your regular shell environment. E.g., most of my test debugging happens via: ./t1234-foo.sh -i cd trash\ directory-1234-foo/ gdb --args ../../git some-command That implies that the test you're interested in is actually failing (though I have been known to insert "false &&" to make it so), and that running the test doesn't wreck the on-disk state. But what if we could do something like: ./t1234-foo.sh --debug=42 to stop _before_ running test 42, print out the commands it would run, and leave the trash directory so that you can inspect it yourself? That does not have the "resume after I'm done inspecting" property that test_pause, but IMHO that is not really that useful for debugging. It will also occasionally cause headaches when a test relies on other parts of the environment (e.g., environment variables defined previously, or functions defined in the script). But I find those are usually a minority of cases. -Peff
