DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2FAD3386181D
Subject: Re: libtool with mingw hangs building openocd in
 func_convert_core_msys_to_w32
To: cygwin@cygwin.com
References: <SN6PR13MB4269FAC268C274507EC43A7EE5039@SN6PR13MB4269.namprd13.prod.outlook.com>
Message-ID: <5578086f-6ac4-70c3-cc74-fe813faac879@gmail.com>
Date: Mon, 28 Jun 2021 09:49:01 -0500
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19)
 Gecko/20081209 Lightning/0.9 Thunderbird/2.0.0.19 Mnenhy/0.7.6.0
MIME-Version: 1.0
In-Reply-To: <SN6PR13MB4269FAC268C274507EC43A7EE5039@SN6PR13MB4269.namprd13.prod.outlook.com>
Content-Language: en-US
Precedence: list
From: =?utf-8?q?Ren=C3=A9_Berber_via_Cygwin?= <cygwin@cygwin.com>
Reply-To: =?UTF-8?Q?Ren=c3=a9_Berber?= <rene.berber@gmail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>

On 6/28/2021 8:56 AM, Dietmar May via Cygwin wrote:

> Thanks for submitting the bug report.
> 
>> I can now see what may be a duplicate report under:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949
>>
>> responding that //c is deliberate so MSYS does not convert a posix path,
>> so in the Cygwin Mingw build case, the response may be "Don't Do That"! 
> 
> I just re-installed msys2 and tried a few things, with interesting result.
> 
> First, "ls /usr//bin" as well as "ls /usr/////bin" complete successfully 
> under both cygwin and msys2, demonstrating slash compaction.
> 
> However, "ls //usr/bin" hangs, as both apparently evaluate the leading 
> // as a server path.

Well documented here:

https://cygwin.com/cygwin-ug-net/using.html#unc-paths

> For testing libtool's construct, I tried:
> 
> $ 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.

> 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

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple