14

I'm writing a command line tool. One of the things this tool can do (certainly not uniquely) is read it's input from stdin. I was testing this interactively (by typing input, rather than cat'ing a file in) when I noticed that I have no clue how to signal EOF to it.

I have spent an inordinate amount of time tonight Googling this and found nothing helpful. I searched SO, as well. Please feel free to point me to a duplicate question, but I did my due diligence, I promise.

EDIT: It might be helpful (?) to mention that I'm doing this on Windows. So I believe the terminal is more or less a branded MinGW?

thepudds
  • 4,787
  • 3
  • 20
  • 37
burfl
  • 2,138
  • 2
  • 20
  • 18

5 Answers5

8

If you're trying to send EOF to a program's input under Windows, Ctrl-Z is what you're looking for.

Brendan Dolan-Gavitt
  • 647
  • 6
  • 21
  • 4
    I had tried that, but was confused that it literally printed "^Z" on the screen. `Ctrl-C` terminates the process without printing anything, so I assumed it was not working. However, after doing `Ctrl-Z `, it worked. A note for those who come along after me: this doesn't seem to work at the end of a line. It would appear it needs to be on its own line. Thank you, @Brendan. – burfl Mar 28 '13 at 02:54
  • 2
    I inadvertently started just `pv` and on `Ctrl-Z` it just prints `87891708 [sig] bash 2363! sigpacket::process: Suppressing signal 18 to win32 process (pid 0)`. How do I get out? – Felix Dombek Oct 03 '21 at 00:57
  • As of 2021, when executed from Git Bash (as the OP specifies in his title), this produces the warning ```1 [sig] bash 804! sigpacket::process: Suppressing signal 18 to win32 process (pid 2032)```. – Josiah Yoder Dec 08 '21 at 17:35
  • 1
    Just executing `some-prog` and then trying this, it seemed to generate the `Suppressing signal 18 to win32 process` warning, but `cat | some-prog` seemed to work better with Git Bash Windows 10, and then a normal Ctrl-D seemed to work to close stdin. Via https://stackoverflow.com/a/70293204/11210494 – thepudds Jan 03 '22 at 18:07
6

A simple work-around that I'm using in Git Bash on Windows is to cat the input to the program.

E.g., instead of running

java my_package.Main

You can run

cat | java my_package.Main

This works because the cat program is a linuxy-program that can accept the end of message from the terminal, and java can receive the end of message command properly through the pipe.

So when using this command, you can type Ctl-D after typing the message and the java program will see the end of message correctly.

Josiah Yoder
  • 3,321
  • 4
  • 40
  • 58
3

It's ^D, the ASCII End of Transmission character. All the GNU-userland tools will use POSIX standards.

jthill
  • 55,082
  • 5
  • 77
  • 137
  • Is that the case on Windows? I just tried sending ^D to GnuWin32's `cat` command, and it didn't do anything. ^Z did exit cat as expected. – Brendan Dolan-Gavitt Mar 28 '13 at 02:52
  • 2
    ^D did not work. The program read it and interpreted it as the literal text "^D". – burfl Mar 28 '13 at 02:57
  • That's Ctrl-D, not the two-character caret-d sequence. I use git bash regularly on windows, so I knew it already, I tested it in the shell before answering just because I happened to be on Windows at the momeent, and I tried it again just now with `cat`. All I can say here is, "works for me". Sorry I don't have a better explanation. – jthill Mar 28 '13 at 03:04
  • The behavior might vary based on the program. `cat` seems to behave better than Java or Go programs (according to https://stackoverflow.com/a/59686569/11210494). – thepudds Jan 03 '22 at 18:15
0

"^d ^d" works for me. Just add this string to the end of the input and it succeed.

KID S
  • 1
0

Prefix the login command with winpty to turn on TTY in Windows:

winpty docker login -u <username>
RAM
  • 475
  • 1
  • 3
  • 14