GNU bug report logs - #49246
[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32

Previous Next

Package: libtool;

Reported by: Brian Inglis <Brian.Inglis <at> SystematicSW.ab.ca>

Date: Sun, 27 Jun 2021 23:09:02 UTC

Severity: normal

Tags: patch

Done: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #21 received at 49246 <at> debbugs.gnu.org (full text, mbox):

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: Brian.Inglis <at> SystematicSW.ab.ca, 49246 <at> debbugs.gnu.org
Subject: Re: bug#49246: closed (Re: bug#49246: [PATCH] libtool with mingw
 hangs in func_convert_core_msys_to_w32)
Date: Wed, 14 Aug 2024 21:10:18 +0300
[Message part 1 (text/plain, inline)]
Hi Brian,

On 14/08/2024 20:40, Brian Inglis wrote:
> This is not a duplicate of that path bug.
> 
> The `cmd //c ...` is not a path, which under Windows would contain 
> backslashes '\', it is an invocation of the Windows console command line 
> shell `cmd`.
> 
> Those slashes are Windows console shell command line option switch 
> characters '/', with `cmd /c ...` meant to be equivalent to `sh -c ...`.
> 
> It includes an invalid Windows options switch '//c', which results in 
> the Windows `cmd` shell being invoked as an interactive console shell, 
> as if invoked with the '/k' switch, but ignoring any provided command 
> string, hanging builds!
> 
> For example, under Cygwin under Windows, I can reproduce this failure:
> 
> $ cmd //c dir
> Microsoft Windows [Version 10.0.19045.4651]
> (c) Microsoft Corporation. All rights reserved.
> 
> C:\...>exit
> $ cmd dir
> Microsoft Windows [Version 10.0.19045.4651]
> (c) Microsoft Corporation. All rights reserved.
> 
> C:\...>exit
> $ cmd /c dir
>   Volume in drive C is SYSSW932GB
>   Volume Serial Number is EE45-4341
> 
>   Directory of C:\usr\local\cygwin64\usr\src\cygport\ca
> 
> 2024-08-14  09:55    <DIR>          .
> 2024-08-14  09:55    <DIR>          ..
> 2024-08-14  01:14    <DIR>          .git
> 2022-09-06  01:28    <DIR>          .github
> 2022-09-06  01:28                55 .gitignore
> 2022-09-06  01:28               103 .gitmodules
> 2022-09-06  01:28               478 AUTHORS
> 2024-05-07  01:50    <DIR>          bin
> 2024-08-14  01:13             1,137 COMMIT_MSG
> 2022-09-06  01:28            35,149 COPYING
> 2022-09-06  01:28            23,006 COPYING-DOCS
> 2024-08-14  01:10    <DIR>          cygclass
> 2024-05-07  01:50             7,981 cygport.spec
> 2024-05-07  01:50    <DIR>          data
> 2023-11-20  22:26    <DIR>          doc
> 2024-05-07  01:50    <DIR>          lib
> 2024-05-07  01:50               655 meson.build
> 2022-09-06  01:28                61 meson_options.txt
> 2024-05-07  01:50            41,198 NEWS
> 2024-05-07  01:50            10,295 README
> 2023-11-20  22:26    <DIR>          testsuite
> 2022-09-06  01:28               335 TODO
> 2022-09-06  01:28    <DIR>          tools
>                12 File(s)        120,453 bytes
>                11 Dir(s)  403,840,393,216 bytes free
> $ sh --c
> sh: 0: Illegal option --
> $ echo $SHELL
> /bin/bash
> $
> 
> As shown above, if you invoke the equivalent `sh --c`, the shell 
> complains about the invalid option and exits, and does not hang around 
> as an interactive shell, but the Windows console command line shell is 
> more "helpful"!
> 
> Even if you put that invalid Windows console command line inside a 
> Windows "batch" `cmd` script, it hangs the script at the interactive 
> console command line, until `exit` is typed interactively:
> 
> $ head t.cmd
> cmd //c dir
> exit
> $ llgo t.cmd
> -rwxr-xr-x 1 12 Aug 14 11:21 t.cmd*
> $ cmd /c t.cmd
> 
> C:\usr\local\cygwin64\usr\src\cygport\ca>cmd //c dir
> Microsoft Windows [Version 10.0.19045.4651]
> (c) Microsoft Corporation. All rights reserved.
> 
> C:\usr\local\cygwin64\usr\src\cygport\ca>exit    <<<--- typed
> 
> C:\usr\local\cygwin64\usr\src\cygport\ca>exit
> $
> 
> I hope that better explains the issue, and am surprised that many folks 
> working on Windows (cross-) builds do not have a better handle on the 
> build environment, and its issues, as these communication issues often 
> recur.
> 
> I characterize that personally as "Shit I shouldn't need to know!", but 
> I have had to, to do stuff like porting shell scripts to Windows `cmd` 
> scripts and utilities, for business continuity and disaster recovery on 
> user's home PCs. ;^>
> 
> If you don't like running Windows, you can always run Cygwin under Wine 
> under Linux, as the two projects interoperate and cooperate, also with 
> Mingw64 and Msys2, so you can get wonderfully lost, as with running 
> under multi-level VMs.
> 

It seems I misunderstood the previous email that made it seem like this
was identified as a duplicate? I have reopened the bug, and I will look
into testing it.

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]
[OpenPGP_signature.asc (application/pgp-signature, attachment)]

This bug report was last modified 278 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.