Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

[Evgeny Grin <k2k@yandex.ru>]

[-- Attachment #1.1.1: Type: text/plain, Size: 5971 bytes --]

Sorry for necroreply. Just to keen in history records.

When starting any program under MSYS (and MSYS2), the MSYS[2] checks 
whether the lunched program is linked with msys-*.dll.
If program is linked with this DLL then the program expects POSIX-like 
environment so no path translation is performed.
If program is not linked with this DLL then the program is native 
Windows binary, which expects native Windows paths. In such case the 
MSYS[2] scans all arguments for POSIX-like paths and converts all of 
them to Windows native paths. The problem is that all Windows drives are 
mounted as single letter in the root so the path like "/d/path/file" 
should be translated into "D:/path/file", while "/c" is translated into 
"C:/"
To prevent this translation double slash could be used. Double slash is 
replaced with single slash.

Examples:

------------------------
MSYS ~
$ cmd /c echo "/c"
Microsoft Windows [Version 10.0.19045.3208]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\user>exit

MSYS ~
$ cmd //c echo "/c"
C:/

MSYS ~
$ cmd //c echo "//c"
/c

MSYS ~
$ cmd //c echo "///c"
//c

MSYS ~
$ echo.exe "/c"
/c

MSYS ~
$ echo.exe "//c"
//c
------------------------
"echo.exe" is Msys program. cmd is not Msys program.

-- 
Evgeny


On 28.06.2021 19:29, Dietmar May via Cygwin wrote:
>> >/$ 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
> 
> 

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 4085 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]