Sadly, I think that T4395 is insufficient to fix the Windows quoting problems. It looks like cmd has a bug when invoked like this:
counterexample
cmd /c ""jshint" "--version""
In this case, jshint is a batch file generated by npm's cmd-shim:
lang=bat, name=jshint.cmd
@IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\node_modules\jshint\bin\jshint" %*
) ELSE (
node "%~dp0\node_modules\jshint\bin\jshint" %*
)
When invoked the way `arc lint` does, `%~dp0` does not get correctly set, so it refers to $CWD instead of the directory containing jshint.cmd. So, `%~dp0\node_modules\jshint\bin\jshint` doesn't resolve, and jshint fails to run.
Specifically, quoting the program name is what trips up cmd, so even invoking `"jshint"` directly in the shell fails. There's a corresponding [[https://github.com/ForbesLindesay/cmd-shim/issues/10|npm bug]] filed, but I think it's worth fixing in phabricator to handle this edge case more robustly.
**Recommendation:** Not quoting the binary but still quoting the rest of the args fixes it (`cmd /c "jshint "--version""`). This solves the problem for binaries without spaces in the names, which should be 99.9% of binaries. If the binary //does// have a space in the name, nothing can save you from `%~dp0` being wrong, as far as I can tell. I made a dummy "js hint.cmd" with the batch code above, and even invoking `"js hint"` directly at the shell screws things up.