[PATCH 1 of 2] tests: restore 'python' and '$TESTDIR/' for dummyssh invocation

Matt Harbison mharbison72 at gmail.com
Wed Jun 10 20:04:34 CDT 2015


On Wed, 10 Jun 2015 12:29:05 -0400, Matt Mackall <mpm at selenic.com> wrote:

> On Wed, 2015-06-10 at 00:00 -0400, Matt Harbison wrote:
>> # HG changeset patch
>> # User Matt Harbison <matt_harbison at yahoo.com>
>> # Date 1433900373 14400
>> #      Tue Jun 09 21:39:33 2015 -0400
>> # Node ID abc40dc68229deb86ecc10ca6cb858211ee6cde3
>> # Parent  ad14fb602e5e54e5432fbc776dd5d1bad63f1f68
>> tests: restore 'python' and '$TESTDIR/' for dummyssh invocation
>>
>> This is a backout of 46727fea7a00, and a partial backout of  
>> c3ecbf694904.
>>
>> Windows won't execute 'dummyssh' directly, presumably because  
>> CreateProcess()
>> doesn't know how to execute a bash script:
>>
>>    $ hg clone -e "dummyssh" ssh://user@dummy/cloned sshclone
>>    remote: 'dummyssh' is not recognized as an internal or external  
>> command,
>>    remote: operable program or batch file.
>>    abort: no suitable response from remote hg!
>>    [255]
>
> Ok, thanks. I was taking the existence of working bare shell and python
> scripts elsewhere in the suite as evidence that they could be executed
> directly. But it seems the story for calls from within Mercurial are
> different (since they're not being evaluated by sh and thus don't know
> about things like shebangs and pseudo-exec-bits).
>
> Perhaps we can make this better for Cygwin/MinGW. If, for instance, we
> have $SHELL in the environment, we can try to invoke commands via the
> shell.

So I tried this:

diff --git a/mercurial/util.py b/mercurial/util.py
--- a/mercurial/util.py
+++ b/mercurial/util.py
@@ -346,6 +346,11 @@
      return stdin, stdout, stderr

  def popen4(cmd, env=None, newlines=False, bufsize=-1):
+    shell = os.environ.get('MSYSCON')  #SHELL
+    if shell is not None:
+        print('shelling out for %s' % cmd)
+        cmd = '%s -c %s' % (shell, shellquote(cmd))
+    print('popen4(%s)' % cmd)
      p = subprocess.Popen(cmd, shell=True, bufsize=bufsize,
                           close_fds=closefds,
                           stdin=subprocess.PIPE, stdout=subprocess.PIPE,


Which fixes the issue for this specific test:

--- c:/Users/Matt/Projects/hg/tests/test-subrepo-relative-path.t
+++ c:/Users/Matt/Projects/hg/tests/test-subrepo-relative-path.t.err
@@ -75,12 +75,16 @@
  subrepo paths with ssh urls

    $ hg clone -e dummyssh ssh://user@dummy/cloned sshclone


But doesn't for absolute paths later in the same test file:

@@ -91,15 +95,13 @@

    $ hg -R sshclone push -e dummyssh ssh://user@dummy/`pwd`/cloned
    pushing to ssh://user@dummy/$TESTTMP/cloned
-  pushing subrepo sub to ssh://user@dummy/$TESTTMP/sub
-  searching for changes
-  no changes found
-  searching for changes
-  no changes found
-  [1]
+  shelling out for dummyssh user at dummy "hg -R $TESTTMP/cloned serve  
--stdio"
+  popen4(sh.exe -c "dummyssh user at dummy \"hg -R $TESTTMP/cloned serve  
--stdio\"")
+  remote: abort: there is no Mercurial repository here (.hg not found)!
+  abort: no suitable response from remote hg!
+  [255]

    $ cat dummylog
    Got arguments 1:user at dummy 2:hg -R cloned serve --stdio
    Got arguments 1:user at dummy 2:hg -R sub serve --stdio
-  Got arguments 1:user at dummy 2:hg -R $TESTTMP/cloned serve --stdio
-  Got arguments 1:user at dummy 2:hg -R $TESTTMP/sub serve --stdio
+  Got arguments 1:user at dummy 2:hg -R  
F;C:\MinGW\msys\1.0\TEMPDIR\hgtests.i7idmk\child1\test-subrepo-relative-path.t\cloned  
serve --stdio


I noticed this in the output when running the test with --debug:

+ hg -R sshclone push -e dummyssh  
ssh://user@dummy/F:/TEMPDIR/hgtests.luprni/child1/test-subrepo-relative-path.t/cloned


I *think* what is going on here is msys thinks '/F:/TEMPDIR...' is a unix  
path list, and Window-izes it to 'F', followed by a path separator,  
converts the next '/' to the underlying Windows path shown in 'df' for  
'/', and appends the rest.  There's no way to disable that behavior IIRC.   
I did some really nasty env variable hacking to get around it at work, but  
no way I would introduce that into the test suite.  We were also having an  
issue with a URL being mangled.

The other odd thing I noticed is that "echo $SHELL" in MinGW will print  
'/bin/sh', but os.environ printed inside util.popen4() from the test  
runner doesn't have $SHELL defined.  Not sure if 'MSYSCON' is portable to  
Cygwin.

Is this something that has a use outside the tests?  I'm not sure how much  
time it's worth spending on this.


More information about the Mercurial-devel mailing list