winpty automatic slash-to-backslash conversion messes commands that need slashes

[mrts]

Environment

• Windows 10 64x
• mintty 2.0.3 from Git Bash
• winpty 0.2.2-dev from Git Bash
• Bash 4.3.42

Problem

Running docker inside mintty fails and there's a correct recommendation to use winpty:

$ docker run -it mrts/python-selenium-xvfb
the input device is not a TTY.  If you are using mintty, try prefixing the command with 'winpty'

However, when using winpty, slashes are converted to backslashes that messes up docker that expects slashes:

$ winpty docker run -it mrts/python-selenium-xvfb
docker: Error parsing reference: "mrts\\python-selenium-xvfb" is not a valid repository/tag.

Expected behavior

Slashes are not converted to backslashes or there is a way to turn this off.

[rprichard]

FWIW, upstream winpty passes arguments through unmodified, which I think matches Cygwin's behavior.

If you can get upstream winpty working with your Git Bash environment, then I think you'd avoid this problem. You could try downloading winpty-0.4.0 from https://github.com/rprichard/winpty/releases/tag/0.4.0. I think you'd need the 32-bit or 64-bit MSYS2 packages according to uname -m.

MSYS2 (and MSYS, IIRC) uses a heuristic to automatically detect Unix-style paths in arguments and convert them to Windows-style paths. IIRC, that conversion behavior isn't exposed from the MSYS2 DLL.

When winpty was packaged for MSYS2, the packager added the argument slash-to-backslash conversion. Eventually, the argument conversion code from MSYS2 was brought into the MSYS2-packaged version of winpty: msys2/MSYS2-packages@f6440fb. That may be something this project should also do. I'm guessing you don't have that version yet, because the MSYS2 conversion heuristic seems to leave foo/bar alone. (OTOH, it will convert something like /foo/bar.)

Slightly related to #81, but not really.

[mrts]

Thanks for the thorough explanation!

[bw4sz]

@mrts Did this solve your problem, i'm having the same issue with git bash.

[k-takata]

MSYS2's automatic path conversion can be controlled by an environment variable MSYS2_ARG_CONV_EXCL.
See: https://sourceforge.net/p/msys2/wiki/Porting/#filesystem-namespaces
(I'm not sure this is the case.)

[rprichard]

MSYS2 has a MSYS2_ARG_CONV_EXCL variable, which is a semicolon-delimited list of prefixes that are matched against arguments, with a special '*' value that matches anything.

It looks the process spawn's argument heuristic has a bunch of additional special cases in Git-for-Windows that aren't in MSYS2. e.g.:

• Git-for-Windows adds a MSYS_NO_PATHCONV variable that (I think) disables the heuristic if get() returns non-NULL.
• Mangling is disabled for paths starting with @@ or paths that look like IPv6 addresses.
• Compare Git-for-windows (https://github.com/git-for-windows/msys2-runtime/commits/msys2-master%2Bgit-for-windows/winsup/cygwin/msys2_path_conv.cc) versus MSYS2 (https://github.com/Alexpux/Cygwin/commits/msys2-master/winsup/cygwin/msys2_path_conv.cc).

The MSYS2-patched winpty uses the argument heuristic on the first argument, which is a mistake. MSYS2 uses path::get_win32() for the first argument instead. (See linebuf::fromargv in the MSYS2 runtime.)

I'm wondering again whether winpty should try to access the MSYS argv -> cmdline translation code. If nothing else, it could use POSIX spawn to start winpty-agent.exe and have it dump the Windows command line (and environment?) to a pipe, then run winpty_open like it does now. It would slow winpty startup.