Why does Go transform os.Args[] with colons in this way (win32/x64)

[Russtopia]

On windows, Go 1.14 running in my case under MSYS64

--

package main
import (
        "fmt"
        "os"
)
func main() {
        for idx, a := range os.Args {
                fmt.Printf("arg[%d]: %s\n", idx, a)
        }
}

$ go run argtest.go foo foo:bar foo:/bar/baz
arg[0]: C:\msys64\tmp\go-build182983234\b001\exe\argtest.exe
arg[1]: foo
arg[2]: foo:bar
arg[3]: foo;C:\msys64\bar\baz

Note that last arg: seems Go converts 'foo:' to 'foo;C:' and then interprets the rest as an absolute unix path to be converted to a DOS-style path!

Is there a good rationale why this is done?

For context, I am writing a utility that I want to specify paths in the style of openssh/scp, eg. hostname:path without Go munging them into Windows-style paths.

[Russtopia]

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.

-Russ

[Axel Wagner]

I'd assume it has nothing to do with Go at all. You should try this with a minimal C program and look at the results. I assume it's something the shell is doing.

--
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 golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN4yCu8eJhi8PhgXWqh%2Bs%2BNJez1zthaGOMUNAcxTyyqe0nnxNw%40mail.gmail.com.

[Kurtis Rader]

On Thu, Jun 11, 2020 at 8:09 PM Russtopia <rma...@gmail.com> 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