Re: [PATCH 0/2] test-lib-functions.sh: keep user's HOME, TERM and SHELL for 'test_pause' and 'debug'

[Elijah Newren <newren@gmail.com>]

On Thu, Aug 19, 2021 at 11:10 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> 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?


> 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