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 :)
CTRL+M is like pressing ENTER. Kernigan & Pike, 1984: UNIX Programming Enviornment
RETURN is an example of a control character — an invisible character that controls some aspect of input and output on the terminal. On any reasonable terminal, RETURN has a key of its own, but most control characters do not. Instead, they must be typed by holding down the CONTROL key, sometimes called CTL or CNTL or CTRL, then pressing another key, usually a letter. For example, RETURN may be typed by pressing the RETURN key or, equivalently, holding down the CONTROL key and typing an ‘m’. RETURN might therefore be called a control-m, which we will write as ctl-m.
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>123catprints 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
catread 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).
Yes, although
Ctrl-Mwould be the “Carriage Return” character (\r). For the “Line Feed” newline character (\n) the Control combination would beCtrl-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^Msymbol at the end of each line.
Ctl-D is the End-of-File character. Programs interpret it as “that’s it, the input you were reading has finished”, and react accordingly.
$ 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.
When running cat this way, you are in “cooked mode”. A ctrl-d does nothing on a non-empty line.
The shell usually runs in non-cokked, or raw, mode as well as nonblocking mode. Where it sees (nearly) every key you press as you press them. Which is why it " sees" the ctrl-d even when you are not on an empty line.
You can learn more here:
- https://jvns.ca/blog/2024/11/26/terminal-rules/#rule-3-repls-should-quit-when-you-press-ctrl-d-on-an-empty-line. (And more generally, from her various blog posts on the matter)
- https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-ref/Terminal-Mode.html
Interesting, I have not heard of these terms before. Thanks for sharing!
I think this adds the bit of nuance that was bugging me: using something like ncurses or vim, presumably when you press a key like ctrl-z or ctrl-d it actually sends the character to the app. It would feel a bit silly if the terminal intercepted the ctrl-d, flushed some buffer, and the program had to reverse engineer whether you pressed ctrl-d or enter or something.
For raw mode, I assume the app asks the tty to please forward some characters to the app. Otherwise, in the default cooked mode, the tty intercepts those control characters to call certain functions. I suppose some REPLs may choose to emulate a cooked mode on top of raw mode, and so they have to handle the \x04 in the same way a tty would to keep it functioning like the user expects. I believe
readlinedoes something like this, which is why you had to usebash --noeditingfor ctrl-d to run the command. Good food for thought :)I also have to say, naming it “cooked mode” is extremely funny as gen z. I love that
A ctrl-d does nothing on a non-empty line.
ctrl-d actually is flushing the buffer regardless of if the line is empty or not.
See my other comment for how you can observe it.
This!
It’s merely a buffer flush, in case it’s empty, the program handling the input can choose how to interpret,
catdecides to do it as an EOF.Reason why it also works as exit.
Ctrl+d terminates input on stdin to your currently running program or shell.
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
For some reason my mobile client didn’t make the article link immediately obvious. That’s actually really interesting. Apparently I was under the same common misconception. So the shell in this case is choosing to continue after detecting the flush.
Ohh I gotcha. Honestly no sweat, its kind of just a bit of fun trivia really :)
deleted by creator
Lol wrong again
