go version go1.15.2 darwin/amd64, cross-compiling for and running on win
I noticed this issue after cross-compiling for win, then running on win. I have only been able to reproduce on Win. I have not tried compiling natively on win to see if the issue also exists under those circumstances
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
For some more context, this only happens with cmd.exe "c:\temp\"flag_bug.exe -h is invalid in powershell
The terminal interprets \" to mean a literal " so the quoting is technically invalid. os.Args reports args as [c:\temp"flag_bug.exe -h]
So there might be something fixable in Go but I'm not sure if that would happen.
The terminal interprets \" to mean a literal " so the quoting is technically invalid.
I do not believe this statement is correct. It may be true in powershell, but it is definitely not true in cmd.exe which has no problem finding and executing the binary. If it was true, then the OS would be looking for a file called temp"flag_bug.exe located in C: and it would fail with a file-not-found error.
The first argument (argv) is treated specially. It represents the program name. Because it must be a valid pathname, parts surrounded by double quote marks (") are allowed. The double quote marks aren't included in the argv output. The parts surrounded by double quote marks prevent interpretation of a space or tab character as the end of the argument. The later rules in this list don't apply.
It is only in a "later rule"-- which explicitly does not apply to argv-- that it then states: "A double quote mark preceded by a backslash (\") is interpreted as a literal double quote mark (")."
Even if this is a known issue that will not be fixed, I have to disagree with the suggestion that this isn't a bug. "my program is running and it cannot find the flags I passed to it" is a bug, regardless of what the technical reasons are for it existing. It would be a different thing if Windows itself interpreted it the way you've suggested, and therefore windows was unable to find and execute the exe. However, that is not the case.