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

[Gregory Szorc]

On Sun, Dec 17, 2017 at 10:44 AM, Matt Harbison <mharbison72 at gmail.com>
wrote:

>
> > On Dec 16, 2017, at 7:27 PM, Matt Harbison <mharbison72 at gmail.com>
> wrote:
> >
> > # HG changeset patch
> > # User Matt Harbison <matt_harbison at yahoo.com>
> > # Date 1513468682 18000
> > #      Sat Dec 16 18:58:02 2017 -0500
> > # Node ID ca9cde0697c1e923f4c9a3396343afc238ba92f2
> > # Parent  d1fbb07b0b7259ae4ca88434e0eda2a21359f7ec
> > test-ssh: convert dumpenv to python for Windows
> >
> > Previously, this complained:
> >
> >    remote: '.' is not recognized as an internal or external command,
> >    remote: operable program or batch file.
> >
> > 1 out of 4 Linux runs failed to print 17 after converting, and instead
> printed
> > an empty remote line.  Not sure why, but maybe the flush will help.
> >
> > diff --git a/tests/test-ssh.t b/tests/test-ssh.t
> > --- a/tests/test-ssh.t
> > +++ b/tests/test-ssh.t
> > @@ -598,17 +598,19 @@
> >   [255]
> >
> > 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"
> >   pulling from ssh://something/
> >   remote:
> >   abort: no suitable response from remote hg!
> >   [255]
> > -  $ hg pull ssh://something --config ui.ssh="./dumpenv" --config
> sshenv.VAR=17
> > +  $ hg pull ssh://something --config ui.ssh="$PYTHON dumpenv.py"
> --config sshenv.VAR=17
> >   pulling from ssh://something/
> >   remote: 17
>
> No idea why, but if I run this in my Linux VM with -j9, it wants to append
> an extra “remote: “ at this point.  If run without workers, it appears
> stable.
>

The flush() shouldn't be necessary because stdio descriptors will get
flushed when process exits. The new Python appears the same as the old
shell script.

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.


> >   abort: no suitable response from remote hg!
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20171217/a697c7a3/attachment.html>