On Thu, Aug 19, 2021 at 11:10 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > > On Thu, Aug 19, 2021 at 1:16 PM Philippe Blain via GitGitGadget > <gitgitgadget@xxxxxxxxx> wrote: > > This series proposes two small quality-of-life improvements (in my opinion) > > to the 'test_pause' and 'debug' test functions: using the original values of > > HOME and TERM (before they are changed by the test framework) and using > > SHELL instead of SHELL_PATH. > > > > The later might be too big of a change, but I think it makes sense. We could > > add a new GIT_TEST_* to conditionnaly change the behaviour, but I kept it > > simple for v1. > > I also find the test_pause() user-experience suboptimal and appreciate > the idea of improving it. However, this approach seems fatally flawed. > In particular, setting HOME to the user's real home directory could > lead to undesirable results. When I'm using test_pause() to debug a > problem with a test, I'm not just inspecting the test state, but I > quite often interact with the state using the same Git commands as the > test itself would use. Hence, it is very common for me to pause the > test just before the suspect commands and then run those commands > manually (instead of allowing the test script to do so). In such a > scenario, HOME must be pointing at the test's home directory, not at > my real home directory. I agree, but I worry that it's not just HOME. I'd think the point of test_pause is to let you interact with the repository state while getting the same results that the test framework would, and I think some tests could be affected by TERM and SHELL too (e.g. perhaps the recent issues with COLUMNS). Granted, I suspect far fewer tests would be affected by those, but I'm not sure I like the idea of inability to reproduce the same issues. Maybe we just need a different construct or special flags to test_pause? > Perhaps there's some way to achieve your goal for at least certain > shells by detecting the shell and taking advantage of special shell > features which allow you to launch the shell and run some canned > commands to set up the shell as desired before dropping into an > interactive session[1] -- but it's just an idle thought. > > [1]: For Bash, for instance, a quick bit of Googling leads to: > https://serverfault.com/a/586272
