Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Dietmar May <dietmar.may@outlook.com>]

> >/$ cmd //c echo hello />/hello />//>/which works, and this, which doesn't: />//>/$ cmd /c echo hello />//>/Microsoft Windows [Version 10.0.blah] />/(c) Microsoft Corporation. All rights reserved. />//>/C:\msys64\home\myname> /
> Your example seems to be inverted, the first form doesn't work, the
> second does with the same results you show (but inverted).
>
> It would be better if you document how you executed those commands,
> we're assuming a mintty terminal running a bash shell, but I haven't
> followed all your messages and it might be a cmd window; results
> shouldn't change anyway, but for completeness sake.

More details for you, then:

 >/I just re-installed msys2 and tried a few things, with interesting 
result. /

I install msys2-x86_64-20210604.exe (downloaded last week) from the 
msys2 website, and accept all defaults during installation, including 
the "run msys2 now" on the final installation screen (which, yes, opens 
a mintty terminal running msys2's bash shell). All commands are executed 
in that same mintty window immediately following a fresh installation.

So here is the output, cut-and-pasted from that mintty terminal:

dietmar@laptop MSYS ~
$ cmd //c echo hello
hello

dietmar@laptop MSYS ~
$ cmd /c echo hello
Microsoft Windows [Version 10.0.19043.1055]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\dietmar>

As you can see, the first form DOES INDEED work, and the second does 
not. Why not try it yourself? You will likely have the same results.

> No, wrong, cmd is getting an argument which it interprets as it seems
> fit, no hack there.  The same applies to the ls example before, ls
> receives an argument which is expected to be a path, nothing strange.
To find out what cmd is really doing, I believe the authoritative answer 
would be given by Microsoft's Command Prompt:

Microsoft Windows [Version 10.0.19043.1055]
(c) Microsoft Corporation. All rights reserved.

C:\Users\dietmar>cmd //c echo hello
Microsoft Windows [Version 10.0.19043.1055]
(c) Microsoft Corporation. All rights reserved.

C:\Users\dietmar>exit

C:\Users\dietmar>

Here we see that cmd.exe //c starts a subshell, rather than executing a 
single command.

However, in msys2's mintty/bash window, that same syntax works differently:

dietmar@laptop MSYS ~
$ cmd //c echo hello
hello

dietmar@laptop MSYS ~
$ cmd ///c echo hello
Microsoft Windows [Version 10.0.19043.1055]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\dietmar>exit
exit

dietmar@laptop MSYS ~
$ cmd ////c echo hello
hello

dietmar@laptop MSYS ~
$ cmd //////c echo hello
hello

dietmar@laptop MSYS ~
$ cmd ////////c echo hello
hello

dietmar@laptop MSYS ~
$ cmd /////////c echo hello
Microsoft Windows [Version 10.0.19043.1055]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\dietmar>exit
exit

dietmar@laptop MSYS ~
$

It seems evident that msys2 is performing slash escaping - ie. 2 
consecutive slashes are consolidated into a single slash (rather like 
quote escaping in various languages - eg. SQL, CSV, C#, YAML) 
recursively (ie. repeatedly) during argument evaluation.

Again, why not simply change this to a form that works without the slash 
hackery?

dietmar@laptop MSYS ~
$ cmd /c "echo hello"
hello

> >/Interestingly, />//>/ls //c />//>/hangs under msys2 (as well as cygwin), /
> Expected as the documentation link describes, //c is taken as a path to
> a server, you already knew that.
>
> >/whereas />//>/cmd //c />//>/does not; so it almost seems like msys2 has a hack to recognize that />/cmd.exe is being invoked ... /
> No, wrong, cmd is getting an argument which it interprets as it seems
> fit, no hack there.  The same applies to the ls example before, ls
> receives an argument which is expected to be a path, nothing strange.
>
> >/However, both of the following also complete successfully under msys2, />/WITHOUT the double-slash hack: />//>/$ cmd /c "echo hello" />/hello />//>/$ cmd "/c" "echo hello" />/hello />//>/Both seem preferable to bad syntax. />//>/Of course, there's always the question of why libtool is using cmd.exe />/instead of /bin/echo, which seems to work just fine ... />//>/$ /bin/echo "hello world" />/hello world /-- 
> R.Berber