On Thu, Jun 11, 2020 at 8:09 PM Russtopia <[email protected]> wrote: > Ah, bad form posting before I tried it in a plain CMD.EXE context. > The args are not transformed running from the vanilla command environment. > Guess it's a nasty interaction with MSYS. >
TL;lDR: http://www.mingw.org/wiki/Posix_path_conversion I can reproduce your problem on a Windows10 + MSYS2 bash session. That is, from a MSYS2 /usr/bin/bash prompt. While it is due to an unexpected interaction with MSYS I too was surprised by the unexpected treatment of arg[3] compared to arg[2]. Especially since neither "foo" or "bar" exist as UNC path prefixes on my system. Too, "/x/y" as an argument gets turned into "X:/y". Furthermore, using the msys bash doesn't exhibit this behavior: $ bash -c 'echo $*' foo foo:bar /bar/baz /x/y foo:bar /bar/baz /x/y If I run both commands from a cmd.exe prompt they behave the same; i.e., neither program has its arguments mangled. The answer lies here: http://www.mingw.org/wiki/Posix_path_conversion Note the first sentence: "For any executable not dependent on msys-1.0.dll, MSYS will convert POSIX paths that are used as arguments to Win32 paths. $ ldd /usr/bin/bash.exe ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fffed7a0000) KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fffecc80000) KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7fffeb3b0000) USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7fffed5c0000) msys-2.0.dll => /usr/bin/msys-2.0.dll (0x180040000) win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7fffeb380000) GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7fffebb60000) gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7fffea730000) msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7fffeb6b0000) ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7fffeb280000) $ ldd path-quirk # from go build path-quirk.go ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fffed7a0000) KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fffecc80000) KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7fffeb3b0000) apphelp.dll => /c/WINDOWS/SYSTEM32/apphelp.dll (0x7fffe87f0000) So the question is how to, or even should, Go programs link against msys-2.0.dll when building under MinGW/MSYS2. Or, is there some other mechanism for suppressing that POSIX path conversion? One solution is documented here: https://stackoverflow.com/questions/7250130/how-to-stop-mingw-and-msys-from-mangling-path-names-given-at-the-command-line. Specifically, putting MSYS2_ARG_CONV_EXCL="*" in the environment when running the Go program suppresses the unwanted path mangling. It is not sufficient to have the env var set when building the program but not when running it. See also https://github.com/msys2/MSYS2-packages/issues/84. In short, this behavior is due to a problematic heuristic in the MSYS2 runtime. Arranging to link against msys-2.0.dll if present would be ideal, but we probably don't want to special-case MSYS2 in the Go build tool chain. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD8rLbCZaS6O%2BRPUCyOCagqXksaaEoq9Yv2MXCjgjgNqcQ%40mail.gmail.com.
