`'c:\windows\system32\cmd.exe' /c echo 123` incorrectly runs cmd.exe
The command in Windows prints 123 and exits immediately:
C:\Users\User>c:\windows\system32\cmd.exe /c echo 123
123
In the msys2 it prints cmd.exe hello header as if it runs w/o any command line and awaits an input.
Sorry my answer is so late, I just found this. Here's a workaround, if there's an actual fix needed I wouldn't know about that...
/x in cygwin indicates a virtual drive mount to the root of drive X:. MSYS2 is "helpfully" converting your oneliner to
C:\windows\system32\cmd.exe C:/ echo 123
If you put a space before a switch, like this
'c:\windows\system32\cmd.exe' ' /c' echo 123
it gets converted to
C:\windows\system32\cmd.exe " /c" echo 123
bypassing this conversion and doing the Right Thing.
the space trick would not always work
cmd.exe ' /c' echo 123 # works
cmd.exe ' /c' "echo 123" # not work
and we have to write
cmd.exe ' /c' echo 123 \&\& exit 1
what about
cmd.exe /c "(where $1 || (help $1 |findstr /V Try)) >nul 2>nul && ($* || exit 0)"
I think my previous idea is wrong; after looking around a bit there are certainly better ways.
MSYS2_ARG_CONV_EXCL="*" cmd.exe /c "echo foo" works, see docs and source. Alternatively, double-slashing the single letter parameter like this cmd.exe //c "echo foo" also works, see here (note these rules/examples will not all apply to MSYS2). These methods both allow the rest of the command to be double-quoted.
@clouds56, if you need to also allow passing parameters containing spaces, cmd.exe //c "where $1 || (help $1 | findstr /V Try) >nul 2>nul" && (cmd.exe //c "$@" || true) seems to work (I don't know if there's a better way to do this).
try cmd.exe ^/C