Note: for novices reading along at home, the notation ^X means hold down the ctrl key and type x (without shift).

ctrl-a though ctrl-z will send ASCII characters 1 through 26, which are called control characters (because they’re for controling things, and also because you can type them by holding down the control key).

^D is the EOF character.

Nope, Chuck Testa: there is no EOF character. ^*

“D” being the fourth letter of the alphabet, sends ASCII character 4, which (as you can see in man ascii) is called EOT or “end of transmission”.

$ stty -a | grep eof
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
$ man stty |grep -A1 eof |head -n2
       eof CHAR
              CHAR will send an end of file (terminate the input)

What this means is that the character specified after eof (by default ^D, aka EOT) is configured to be intercepted (by the tty driver) and, instead of that character being sent to the process reading standard input, the kernel will “send an end of file (terminate the input)”.

But “send an end of file” does not mean sending any character to the reading process: as the blog post explains, it actually (counterintuitively) means flushing the buffer - meaning, causing the read syscall to return with whatever is in the buffer currently.

It is confusing that this functionality is called eof, and the stty man page description of it is even more so, given that it (really!) does actually flush the contents of the buffer to read - even if the line buffer is not empty, in which case it is not actually indicating end-of-file!

You can confirm this is happening by running cat and typing a few characters and then hitting ^D. (cat will echo those characters, even though you have not hit enter yet.)

Or, you can pipe cat into pv and see that ^D also causes pv to receive the buffer contents prior to hitting enter.

I guess unix calls this eof because this function is most often used to flush an empty buffer, which is how you “send an end of file” to the reader.

The empty-read-means-EOF semantics are documented, among other places, in the man page for the read() syscall (man read):

On success, the number of bytes read is returned (zero indicates end of file)

If you want ^D to send an actual EOT character through to the reading process, you can escape it using the confusingly-named lnext function, which by default triggered by the ^V control character (aka SYN, “synchronous idle”, ASCII character 22 - note V is the 22nd letter of the alphabet):

$ man stty|grep lnext -A1
       * lnext CHAR
              CHAR will enter the next character quoted
$ stty -a|grep lnext
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;

Try it: you can type echo " and then ^V and ^D and then "|xxd (and then enter) and you will see that this is sending ascii character 4.

You can also send it with echo -e '\x04'. Note that the EOT character does not terminate bash:

$ echo -e '\x04\necho see?'|xxd
00000000: 040a 6563 686f 2073 6565 3f0a            ..echo see?.
$ echo -e '\x04\necho see?'|bash
bash: line 1: $'\004': command not found
see?

As you can see, it instead interprets it as a command.

$ echo -e '#!/bin/bash\necho lmao' > ~/.local/bin/$(echo -en '\x04')
$ chmod +x ~/.local/bin/$(echo -en '\x04')
$ echo -e '\x04\necho see?'|bash
lmao
see?

To be more precise, it’s the “EOT” (end of transmission) control character, the 4th symbol in ASCII, from the non-printable character area.

$ cat
You sound very nice :)
You sound very nice :)
Bye<ctl-d>Bye

Oh wait, and cool too
Oh wait, and cool too
<ctl-d>
$ 

The Ctl-D didn’t end the file when i typed “Bye” :( it only worked when I pressed Ctl-D on its own line. So how does cat know that it should ignore the EOF character if there is some text that comes before it?

What Ctl-D does is flush the input to the program, and the program sees how big that input is. If the length of the input is 0 that is interpreted as EOF. So Ctl-D is like Enter because they both flush the input, but Ctl-D is unlike Enter because it does not append a newline before flushing, and as a consequence you can send empty input (aka an EOF “character”) with Ctl-D.

Yes, although Ctrl-M would be the “Carriage Return” character (\r). For the “Line Feed” newline character (\n) the Control combination would be Ctrl-J. Both of them would normally produce a new line when you press them on most terminals.

That’s why if you open in nano/vim a file with Windows style EOL (/r/n), you might see a strange ^M symbol at the end of each line.

On any reasonable terminal, RETURN has a key of its own

This reminds me of a time at work when I was not on a reasonable terminal. I was explaining to a co-worker how I automated some tasks by running some scripts, but in my demo my RETURN key didn’t work, so I had to improvise and use CTRL+M which worked, hahaha. I don’t know how the terminal got in such a bad spot but it was probably something to do with msys on Windows… honestly not sure. It was perfect timing to have happen while teaching of course ;)

I would also be doing a disservice not to share what the book you linked says about CTRL+D. Right after your quote, it says:

Other control characters include ctl-d, which tells a program that there is no more input

This is pretty good for an introduction, but it is not the full story. It explains CTRL+D properly later (chapter 2, page 45):

Now try something different: type some characters and then a ctl-d rather than a RETURN:

$ cat -u
123<ctl-d>123

cat prints the characters out immediately. ctl-d says, “immediately send the characters I have typed to the program that is reading from my terminal.” The ctl-d itself is not sent to the program, unlike a newline. Now type a second ctl-d, with no other characters:

$ cat -u
123<ctl-d>123<ctl-d>$

The shell responds with a prompt, because cat read no characters, decided that meant end of file, and stopped. ctl-d sends whatever you have typed to the program that is reading from the terminal. If you haven’t typed anything, the program will therefore read no characters, and that looks like the end of the file. That is why typing ctl-d logs you out — the shell sees no more input. Of course, ctl-d is usually used to signal an end-of-file but it is interesting that it has a more general function.

This is why the article says it’s “like pressing enter,” because it flushes the input just like enter. The difference is that enter sends a newline, but CTRL+D does not, so you can exploit that to send no data (and the program chooses to interpret that as an EOF).

not true. try this:

$ date<C-d>

bash did not terminate stdin, because when i press enter it still runs the command, and my shell continues to work as normal!

you can also try this:

$ bash --noediting
$ date<C-d><C-d>

and it will print the date.

so something else is happening here! thats what the link talks about in detail