[PATCH 3 of 3] test-ssh: convert dumpenv to python for Windows

[Yuya Nishihara]

On Thu, 21 Dec 2017 16:49:07 -0500, Matt Harbison wrote:
> > On Dec 17, 2017, at 2:42 PM, Matt Harbison <mharbison72 at gmail.com> wrote:
> >> On Dec 17, 2017, at 2:07 PM, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> >>> On Sun, Dec 17, 2017 at 10:44 AM, Matt Harbison <mharbison72 at gmail.com> wrote:
> >>> > test that custom environment is passed down to ssh executable
> >>> > -  $ cat >>dumpenv <<EOF
> >>> > -  > #! /bin/sh
> >>> > -  > echo \$VAR >&2
> >>> > +  $ cat >>dumpenv.py <<EOF
> >>> > +  > from __future__ import print_function
> >>> > +  > import sys
> >>> > +  > from mercurial import encoding
> >>> > +  > print('%s' % encoding.environ.get('VAR', ''), file=sys.stderr)
> >>> > +  > sys.stderr.flush()
> >>> >> EOF
> >>> > -  $ chmod +x dumpenv
> >>> > -  $ hg pull ssh://something --config ui.ssh="./dumpenv"
> >>> > +  $ hg pull ssh://something --config ui.ssh="$PYTHON dumpenv.py"

Perhaps the simplest workaround is setting ui.ssh="sh dumpenv"?

> >> I suspect we are encountering a preexisting race condition. I suspect the Python version is more susceptible to it because of Python process startup overhead. Before, the shell script likely ran in ~1ms. Now, it takes >10ms. That may be enough to perturb the race condition.
> 
> An additional data point: I ran without workers, with —loop, and it failed the same way in 3 out of 444 runs on the same Linux VM.

IIRC, the order of "remote:" messages was historically unstable as we do
select() channels asynchronously. I won't be surprised if there's another
issue.