Honestly I had no idea what ctrl+d even did, I just knew it was a convenient way for me to close all the REPL programs I use. The fact that it is similar to pressing enter really surprised me, so I wanted to share this knowledge with you :)
Honestly I had no idea what ctrl+d even did, I just knew it was a convenient way for me to close all the REPL programs I use. The fact that it is similar to pressing enter really surprised me, so I wanted to share this knowledge with you :)
It’s not. You keep insisting that ^D doesn’t send EOF and yet:
^D is the EOF character. The thing is that in C every line of a text file must be terminated by a new-line. And so, when you end a file with ^D without a return, you get funky results.
Note: for readers who aren’t aware, 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).
Nope, Chuck Testa: there is no EOF character. Or, one could also say there is an EOF character, but which character it is can be configured on a per-tty basis, and by default it is configured to be
^D
- which (since “D” is the fourth letter of the alphabet) is ASCII character 4, which (as you can see inman ascii
) is called EOT or “end of transmission”.What that
stty
output means is that^D
is the character specified to triggereof
. That means this character is intercepted (by the kernel’s tty driver) and, instead of sending the character to the process reading standard input, the tty “will send an end of file (terminate the input)”.By default
eof
is^D
(EOT), a control character, but it can be set to any character.For instance: run
stty eof x
and now, in that terminal, “x” (by itself, without the control key) will be the EOF character and will behave exactly as^D
did before. (The rest of this comment assumes you are still in a normal default terminal where you have not done that.)But “send an end of file” does not mean sending EOT or any other 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 thestty
man page description of it is even more so, given that it (really!) does actually flush the contents of the buffer toread
- 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
, and then typing more, and hitting^D
again. (Each time you flush the buffer,cat
will immediately echo the latest characters that had been buffered, even though you have not hit enter yet.)Or, you can pipe
cat
intopv
and see that^D
also causespv
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 theread()
syscall (man read
):If you want to send an actual
^D
(EOT) character through to the process reading standard input, you can escape it using the confusingly-namedlnext
function, which by default is bound to the^V
control character (aka SYN, “synchronous idle”, ASCII character 22):$ 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 ctrl-V and ctrl-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.
(Control characters are perfectly cromulent filenames btw...)
$ 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.