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).