Input is no longer buffered when running a Windows program.

[jlennox]

• Your Windows build number: (Type ver at a Windows Command Prompt)

Does not work in: Microsoft Windows [Version 10.0.18362.113]
Does work in: Microsoft Windows [Version 10.0.17134.765]

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

I use git.exe from WSL. Typically I'll begin typing the next command prior to the previous finishing. In 10.0.17134.765 the input would appear in bash after git.exe finished. Now in 10.0.18362.113 it does not.

This can be synthetically reproduced by typing while a slow .exe is running.

Working in 10.0.17134.765

joe@JOE-PC in ~ λ cmd.exe /C "ping -n 6 127.0.0.1"

Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
I am tReply from 127.0.0.1: bytes=32 time<1ms TTL=128
yping bReply from 127.0.0.1: bytes=32 time<1ms TTL=128
efore it cReply from 127.0.0.1: bytes=32 time<1ms TTL=128
ompletesReply from 127.0.0.1: bytes=32 time<1ms TTL=128

Ping statistics for 127.0.0.1:
    Packets: Sent = 6, Received = 6, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
joe@JOE-PC in ~ λ I am typing before it completes.

Not working in 10.0.18362.113

joe@JOE-PC2 in ~ λ cmd.exe /C "ping -n 6 127.0.0.1"
'\\wsl$\Ubuntu\home\joe'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.

Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Ping statistics for 127.0.0.1:
    Packets: Sent = 6, Received = 6, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
joe@JOE-PC2 in ~ λ

• What's wrong / what should be happening instead:

The input should still be getting buffered like it did in 10.0.17134.765.

• Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).

Please let me know if this is required.

[therealkenc]

Problem isn't buffering, it is the path. Run the command with a CWD of /mnt/c. This regressed around 18342 I think. This has broken the go-to way of getting to your windows home.

$ cd $HOME  && echo $PWD
/home/ken
$ cd $(wslpath $(cmd.exe /c "echo %USERPROFILE%") | tr -d '\r')
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
$ cd /mnt/c
$ cd $(wslpath $(cmd.exe /c "echo %USERPROFILE%") | tr -d '\r')
$ echo $PWD
/mnt/c/Users/there

[jlennox]

@therealkenc I'm sorry, I'm not following the relationship. Was this intended to respond to #4078?

[therealkenc]

I'm not following the relationship

The relationship is, from your OP:

[...]
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
[...]

And from my previous post

[...]
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
[...]

Does your scenario reproduce when then command is executed from cd /mnt/c (contrast ~) with 18362.

[therealkenc]

Alright I see now. Two problems, one post. I zeroed on your UNC path fail. More straightforward repro for the problem (the one you care about).

$ cd /mnt/c    # for the other thing
$ cmd.exe /c sleep 10
[type something... tty input blackholes]

[jlennox]

Ah thank you. I've added a clearer description to the case.

[therealkenc]

Great, thanks. As an aside:

I use git.exe from WSL

Nothing good comes of that; at least for now. No need to explain why you are using git.exe instead of Linux /usr/bin/git. I understand. The council is free either way. Ref msft/vscode# 9502 et al.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!