From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) by sourceware.org (Postfix) with ESMTPS id 2FAD3386181D for ; Mon, 28 Jun 2021 14:49:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2FAD3386181D Received: by mail-qk1-x72f.google.com with SMTP id f6so3280184qka.0 for ; Mon, 28 Jun 2021 07:49:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=txa0gc+Du0r1h/Z4zQkZoKnVsKQFE5e3YHEJFeXcX9Y=; b=uIKNp1NNAFBDT5BNm9MgQSlKgndUBqC7bVmEdSB5fu8c0ab1zHkx7x+SYQ73XLNnhs zG1sBbF3DsLMA3gUq3VcF8GBwf9zCMeZaFSKWPgX50j/dGYPa+9uiG19grprlwu+AJRt e6K7RKtkDP6+aa/Tn+jNNFeBRdUZ+QupZB5G9wDN7QhCh9uJOh08/eOGcJ8oKrLCQrUi NTRJ0V+XF13U7Mdd/pHPLX/3Xc4HfcWnbIomdi/4NlOU5zI5dTkxTej8soxCCV49ipep HtSVmL3kT20JJ7fCo7Zyj6Yh9iBE/iD1BGphbJ7wwWimrrIA8GkK63uvZ68h6xHSLPR8 BJDg== X-Gm-Message-State: AOAM530Ao67t/GwsMPvQ8/ih2PD5o7FiaiKwxOTZBw9xgJEUJnU9kyRf 4bgqLWGjtFPtopXDaXsADFKNzYhI+uciOg== X-Google-Smtp-Source: ABdhPJzhSjUwVyCtjsr8ZDtk1QRcHNOqKWBOvC9J0QT0UfPCBjG6s2h16WqNcaV2fzj9iqn3YvxUzQ== X-Received: by 2002:a37:a78d:: with SMTP id q135mr16902614qke.297.1624891743561; Mon, 28 Jun 2021 07:49:03 -0700 (PDT) Received: from [192.168.10.3] (dial-200-57-195-23.zone-3.ip.static-ftth.axtel.net.mx. [200.57.195.23]) by smtp.gmail.com with ESMTPSA id t62sm10488816qkc.26.2021.06.28.07.49.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Jun 2021 07:49:03 -0700 (PDT) Subject: Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32 To: cygwin@cygwin.com References: From: =?UTF-8?Q?Ren=c3=a9_Berber?= 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 14:49:05 -0000 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