[libcxx] [test] Extend test for bash for executor-has-no-bash

If %{exec} sets "--env PATH=single-dir", the directory containing
bash and related shell utils is omitted from the path, which means
that most shell scripts would fail.

(Setting PATH is needed for DLL builds on Windows; PATH fills the same
role as e.g. LD_LIBRARY_PATH on Linux.)

This condition is missed in the current test, because the executor
run.py first resolves the executable to run using the original path,
then invokes that executable with an environment with a restricted
path. Thus the executor is able to run bash, but that bash is then
unable to run further shell commands (other than bash builtins).

Extend the test from "bash --version" to "bash -c 'bash --version'".
This correctly identifies the executor-has-no-bash condition in the
current Windows CI configs, allowing removing 6 cases of
LIBCXX-WINDOWS-FIXME.

Another longterm fix would be to extend run.py with an option like
"--env-prepend PATH=dir", to allow keeping the current path while
adding a directory to it.

Differential Revision: https://reviews.llvm.org/D116117

libcxx/test/std/input.output/iostream.objects/narrow.stream.objects/cerr.sh.cpp

@@ -10,8 +10,6 @@
 
 // istream cerr;
 
-// XFAIL: LIBCXX-WINDOWS-FIXME
-
 // UNSUPPORTED: executor-has-no-bash
 // FILE_DEPENDENCIES: ../check-stderr.sh
 // RUN: %{build}

libcxx/test/std/input.output/iostream.objects/narrow.stream.objects/clog.sh.cpp

@@ -10,8 +10,6 @@
 
 // istream clog;
 
-// XFAIL: LIBCXX-WINDOWS-FIXME
-
 // UNSUPPORTED: executor-has-no-bash
 // FILE_DEPENDENCIES: ../check-stderr.sh
 // RUN: %{build}

libcxx/test/std/input.output/iostream.objects/narrow.stream.objects/cout.sh.cpp

@@ -10,8 +10,6 @@
 
 // istream cout;
 
-// XFAIL: LIBCXX-WINDOWS-FIXME
-
 // UNSUPPORTED: executor-has-no-bash
 // FILE_DEPENDENCIES: ../check-stdout.sh
 // RUN: %{build}

libcxx/test/std/input.output/iostream.objects/wide.stream.objects/wcerr.sh.cpp

@@ -11,7 +11,6 @@
 // istream wcerr;
 
 // XFAIL: libcpp-has-no-wide-characters
-// XFAIL: LIBCXX-WINDOWS-FIXME
 
 // UNSUPPORTED: executor-has-no-bash
 // FILE_DEPENDENCIES: ../check-stderr.sh

libcxx/test/std/input.output/iostream.objects/wide.stream.objects/wclog.sh.cpp

@@ -11,7 +11,6 @@
 // istream wclog;
 
 // XFAIL: libcpp-has-no-wide-characters
-// XFAIL: LIBCXX-WINDOWS-FIXME
 
 // UNSUPPORTED: executor-has-no-bash
 // FILE_DEPENDENCIES: ../check-stderr.sh

libcxx/test/std/input.output/iostream.objects/wide.stream.objects/wcout.sh.cpp

@@ -11,7 +11,6 @@
 // istream wcout;
 
 // XFAIL: libcpp-has-no-wide-characters
-// XFAIL: LIBCXX-WINDOWS-FIXME
 
 // UNSUPPORTED: executor-has-no-bash
 // FILE_DEPENDENCIES: ../check-stdout.sh

libcxx/utils/libcxx/test/features.py

@@ -75,8 +75,14 @@ DEFAULT_FEATURES = [
 
   # Whether Bash can run on the executor.
   # This is not always the case, for example when running on embedded systems.
+  #
+  # For the corner case of bash existing, but it being missing in the path
+  # set in %{exec} as "--env PATH=one-single-dir", the executor does find
+  # and executes bash, but bash then can't find any other common shell
+  # utilities. Test executing "bash -c 'bash --version'" to see if bash
+  # manages to find binaries to execute.
   Feature(name='executor-has-no-bash',
-          when=lambda cfg: runScriptExitCode(cfg, ['%{exec} bash --version']) != 0),
+          when=lambda cfg: runScriptExitCode(cfg, ['%{exec} bash -c \'bash --version\'']) != 0),
 
   Feature(name='apple-clang',                                                                                                      when=_isAppleClang),
   Feature(name=lambda cfg: 'apple-clang-{__clang_major__}'.format(**compilerMacros(cfg)),                                          when=_isAppleClang),