Checking EOF of stdio PIPE is broken running Windows executable with WSL2

[LumaKernel]

First, I placed all files to explain this issue at https://github.com/LumaKernel/issue-WSL2-pipe .

a.c is small program enough to reproduce this issue. ( Simple program to read lines and print unless it finds EOF. )

a.exe is compiled with gcc.exe a.c.
a.linux.out is compiled with gcc a.c.

I found the same issue with Go and Rust programs (including clip.exe ( one shipped from Microsoft ;) ), win32yank, my small Go program and powershell.exe (see below) ).

This issue doesn't happen with Linux Programs.

Environment

$ # All below commands are run with bash.
$ # using WSL2
$ echo $SHELL
/bin/bash
$ uname -a
Linux MyComputer 4.19.104-microsoft-standard #1 SMP Wed Feb 19 06:37:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ cat /proc/version
Linux version 4.19.104-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Feb 19 06:37:35 UTC 2020
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.4 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.4 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
$ which gcc.exe  # This is shipped from `scoop install gcc` ( actually mingw-w64's one )
/mnt/c/Users/luma/scoop/apps/gcc/current/bin/gcc.exe
$ which gcc
/home/linuxbrew/.linuxbrew/bin/gcc

winver.exe is saying...

ver and wsl -l -v in cmd is saying...

C:\Users\luma>ver

Microsoft Windows [Version 10.0.20180.1000]

C:\Users\luma>wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu                 Running         2
  docker-desktop         Running         2
  Ubuntu-18.04           Stopped         1
  docker-desktop-data    Running         2
  Alpine                 Running         2

And I tested with Windows Terminal.

Steps to reproduce

The piping is broken if checking EOF in program.
Windows executable program will wait user input.

$ ./a.exe < sample.txt  # works well with file input
61 0a    |a.|
62 0a    |b.|
FOUND EOF!!
$ echo a | ./a.exe  # not working well
61 0a    |a.|
^C$
$ # After at least 3 seconds, but not reaching EOF
$ # and I hit CTRL-C to stop a program.
$ # same
$ cat sample.txt | ./a.exe
61 0a    |a.|
62 0a    |b.|
^C$

Below is using linux native executable ( and this is the expected behavior. )

$ ./a.linux.out < sample.txt
61 0a    |a.|
62 0a    |b.|
FOUND EOF!!
$ cat sample.txt | ./a.linux.out
61 0a    |a.|
62 0a    |b.|
FOUND EOF!!

This may have happened after installing update of WSL2 Linux Kernel from here. It was working well before installing this.

Q. Works with single line read ?

A. Yes.

$ echo -ne "a\x0a" | powershell.exe -c "Read-Host"
a
a

$

Q. Works good with CRLF ?

A. No.

$ echo -en "a\x0d\x0ab\x0d\x0a\x0d\x0a" | ./a.exe
61 0a    |a.|
62 0a    |b.|
0a     |.|
^C$

Expected behavior

Windows executable exits having found EOF.

Actual behavior

Windows executable program will stop working without exiting.

[therealkenc]

/dupe #5648 did not make 20180.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!