Fix tests of `gix-command` external commands on Windows

Two tests of `gix-command` for external commands used `ls` on Unix-like systems and `dir.exe` on Windows. But Windows does not ship a `dir.exe` command, as `dir` in the `cmd.exe` shell is a builtin and `dir` in PowerShell is an alias to a builtin cmdlet. The reason `dir.exe` often worked is that Git Bash and other MSYS2 (or MSYS or Cygwin) environments provide GNU `ls`, which actually supplies three commands, `ls`, `dir`, and `vdir`, which differ by their default options but otherwise behave the same. When no such environment's `bin` directories are in `PATH`, attempting to run `dir.exe` will generally fail, causing the tests to fail. This replaces `dir.exe` with `attrib.exe` and, in the test that passes an argument, adjusts the argument accordingly. (The argument substitution does not preserve meaning, but it is a reasonable argument to pass to `attrib.exe`.) Although `attrib.exe` can be used to set attributes, these commands do not do so (and also avoid appearing to do so). Two commands that are typically present in `System32`, including in native Windows containers and even Nano Server containers, are, very roughly speaking, similar to `ls`, in that they provide filesystem metadata and will do so both implicitly on the current directory or explicitly on specified entries. One is `icacls`, which has the advantage of returning nonzero when it runs but fails, but the disadvantage that it fails when run on an entry in a 9P share accessed from the Windows side. (Shares appearing as network shares that provide access to installed WSL2 distributions' filesystems are 9P shares. There might also be more uses of 9P in Windows in the future.) The other is `attrib`, which has the disavantage of returning zero even when it runs but fails, but the advantage that it work in 9P shares. `attrib` does usually fail when passed the root directory of a filesystem (which is strange), but this is both fairly unlikely in the current use and also acceptable since it still returns zero. Failing to run the command at all will of course not appear like success, which is what really matters. Another command that is sometimes useful for testing the ability to run external commands, and that is present even in Nano Server containers, is `hostname`. However, this can only reasonably be called with zero arguments for testing, since calling it with more arguments fails if the Windows `hostname` command is found, but may do something else such as attempting to set the hostname if the Git Bash (or other MSYS2, etc.) version is found.

EKEliah Kagan committed 10 months ago