I personally think we should never use bash on Windows (wsl being the exception but that won’t identify as Windows anyway).  There’s value in consistency and in my ideal world the lit shell would be feature rich enough that we wouldn’t have to use bash *anywhere*.  In any case right now the configuration matrix is Windows (lit shell) and non Windows (bash).  I don’t think we should grow this by supporting Windows (bash)<br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 3, 2018 at 8:17 AM Greg Bedwell via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">gbedwell created this revision.<br>
gbedwell added reviewers: ddunbar, zturner, rnk.<br>
Herald added a subscriber: delcypher.<br>
<br>
I've been putting up with a couple of failing tests locally for a little while now and finally made the time to investigate the problem:<br>
<br>
  Failing Tests (2):<br>
      lit :: shtest-format.py<br>
      lit :: shtest-run-at-line.py<br>
<br>
This seemed to be happening on my PC only.  Digging deeper, I found this error nested deep in the logs:<br>
<br>
  ******************** TEST 'shtest-format :: external_shell/fail.txt' FAILED ********************<br>
  Script:<br>
  --<br>
  : 'RUN: at line 3';   echo "line 1: failed test output on stdout"<br>
  : 'RUN: at line 4';   echo "line 2: failed test output on stdout"<br>
  : 'RUN: at line 5';   cat "does-not-exist"<br>
  --<br>
  Exit Code: 127<br>
<br>
  Command Output (stderr):<br>
  --<br>
  /bin/bash: E:workupstream-llvmbuild-vs2015-native-ninjautilslittestsInputsshtest-formatexternal_shellOutputfail.txt.script: No such file or directory<br>
<br>
  --<br>
<br>
It turns out that the problem was that WSL installation had placed bash.exe in C:\windows\system32 which was now used in preference to my other version of bash ("C:\Program Files\Git\usr\bin\bash.exe").  The primary difference being that unlike git's bash.exe, WSL's bash.exe can't cope with being invoked with<br>
<br>
  bash.exe c:\\foo\\script.sh<br>
<br>
and would instead need to be invoked with:<br>
<br>
  bash.exe /mnt/c/foo/script.sh<br>
<br>
I've worked around the problem by just changing the order of paths in my environment variable so that git bash gets preference, but to save someone else running into the same thing, here's an attempt at fixing it.  It's not the most elegant solution, but seems the least intrusive in terms of changing current behaviour.<br>
<br>
An obvious question is whether we should ever be using bash on Windows, considering everything seems to pass without it anyway.  Is there a specific use-case for that combination or could we just force it to use 'cmd /c' in TestRunner::executeScript when on Windows for all cases nowadays?<br>
<br>
<br>
<a href="https://reviews.llvm.org/D52831" rel="noreferrer" target="_blank">https://reviews.llvm.org/D52831</a><br>
<br>
Files:<br>
  utils/lit/lit/LitConfig.py<br>
<br>
<br>
Index: utils/lit/lit/LitConfig.py<br>
===================================================================<br>
--- utils/lit/lit/LitConfig.py<br>
+++ utils/lit/lit/LitConfig.py<br>
@@ -120,6 +120,17 @@<br>
         if self.bashPath is None:<br>
             self.bashPath = ''<br>
<br>
+        # Check whether the found version of bash is able to cope with paths in<br>
+        # the host path format. If not, don't return it as it can't be used to<br>
+        # run scripts. For example, WSL's bash.exe requires '/mnt/c/foo' rather<br>
+        # than 'C:\\foo' or 'C:/foo'.<br>
+        if self.isWindows and self.bashPath:<br>
+            command = [self.bashPath, '-c',<br>
+                       '[[ -f "%s" ]]' % self.bashPath.replace('\\', '\\\\')]<br>
+            _, _, exitCode = lit.util.executeCommand(command)<br>
+            if exitCode:<br>
+                self.bashPath = ''<br>
+<br>
         return self.bashPath<br>
<br>
     def getToolsPath(self, dir, paths, tools):<br>
<br>
<br>
</blockquote></div>