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
.
> 2024-08-14 09:55 ..
> 2024-08-14 01:14 .git
> 2022-09-06 01:28 .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 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 cygclass
> 2024-05-07 01:50 7,981 cygport.spec
> 2024-05-07 01:50 data
> 2023-11-20 22:26 doc
> 2024-05-07 01:50 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 testsuite
> 2022-09-06 01:28 335 TODO
> 2022-09-06 01:28 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