Vagrant output doesn't wrap correctly about cbwin HOT 4 OPEN

That behaviour is caused by the Windows Console. For other programs (e.g. tasklist), I noticed that a workaround is to launch wcmd echo. before (actually anything that launches cmd and makes it outputs something on the console, echo. being command producing the less output I could think of). Can you give it a try?

I think I'll make that be launched automatically at the beginning of each session. I would prefer to find the equivalent Win32 calls that fix everything, but the win32 calls tracing feature of windbg is actually broken in Win10 (how do MS devs debug their stuff with broken tools?!?) and I had no more luck with other 3rd party tools, so I think I'll just go with launching wcmd echo.

from cbwin.

With tmux running wrun vagrant provision with ansible output seems normal to me

from cbwin.

I'm using a wrapper script to play nice with the rest of the tooling. So far, tried two solutions that work:

#!/bin/sh
wcmd echo. > \\\\.\\NUL
wrun vagrant $@
exit $?

^ basically @xilun's solution, but redirected to the NUL device (i.e Windows's equivalent for /dev/null) to avoid printing an extra line

After bit of RTFM'ing, I've settled for:

#!/bin/sh
wrun --force-redirects vagrant $@
exit $?

from cbwin.

Some technical details: cmd.exe changes the Console modes (probably as with SetConsoleMode) and cbwin doesn't touch it (except in an experimental branch).
Unfortunately changing console modes back and forth seems to not be enough in Win10 1607 to get the console input working properly when both WSL and Win32 processes are running -- however something probably good enough can be achieved for the output.

The --force-redirects prevents the Win32 process from accessing the console at all (well, if it really wants to, it can reopen it, but most Win32 program won't do that...), because it redirects stdin, out and err to TCP sockets to the WSL side, where the launcher copy the data from/to its own TTY fds.

One of the drawback of how I implemented redirections is that it breaks flow control a little on stdin, because even if the Win32 process would never have read any data, the WSL caller will read and send any stdin data through the socket, until its buffer are full. I can't do much about that, but I think MS interop (for now in Insider versions only) can directly bridge a WSL pipe end to Win32 pipe end, so hopefully that kind of imperfect behaviour will be avoided with native MS interop.

from cbwin.