Re: [PATCH 0/2] test-lib-functions.sh: keep user's HOME, TERM and SHELL for 'test_pause' and 'debug'
- From
Elijah Newren <newren@gmail.com>
- Date
- Aug 19, 2021, 20:03 UTC
- Message-ID
- <CABPp-BFKEoHTgdSnUO86zSPYR0mLHv-vUB+Z-SoTtYQbUY4H=Q@mail.gmail.com>
- In-Reply-To
- <CAPig+cT2FfaYBbsRMy7vxXkvsxn4BcFTn4bGJjgvJKznXg1OYg@mail.gmail.com>
On Thu, Aug 19, 2021 at 11:10 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 23 quoted lines
> > On Thu, Aug 19, 2021 at 1:16 PM Philippe Blain via GitGitGadget > <gitgitgadget@gmail.com> 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?
Show 8 quoted lines
> 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