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

On Thu, Aug 19, 2021 at 11:10 AM Eric Sunshine [off-list ref] wrote:

On Thu, Aug 19, 2021 at 1:16 PM Philippe Blain via GitGitGadget
[off-list ref] wrote:

quoted

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