Response to a recent claim that Ctrl+D in the terminal is like pressing Enter. It kind of is but it’s also misleading to say so without further explanation.
I often exit a shell with ctrl+d. And I often see if a shell is still connected by pressing enter. They are definitely not equivalent.
👆
Let’s say it together: No, it isn’t
Betteridge strikes again
Describing the outcomes in terms of functions over shell states, as you have, is the quickest and most transparent way of demonstrating that they aren’t the same.
The article was a fun “scenic route” to the same conclusion, though.
Control-D gives a hex value of 0x04, where as ENTER or CR gives a hex value of 0x0d,
they are not the same. Control D returns the carriage on old tty machines, on many modern linux platforms it is treated as CRLF, that is carriage return and a linefeed. Control-D indicates end of file or end of transmission.Ctrl+D sends EOF, so no it’s not like enter.
Yes, I agree. But the dispute is what ‘sends EOF’ actually means. The article I respond to claims Ctrl+D doesn’t send EOF but is like Enter except that new line character is not sent. This is, in some sense true, but as I explain also misleading.
To me, the potential point of confusion is referring to “sent by Ctrl+D” and things “received by the end process” as synonymous, ignoring the tty driver in between. When you Ctrl+d, you send a magic byte value to the tty master (which I would refer to as a EOF character, but I understand the argument against the terminology). On the other side of it the process doesn’t receive this value, but instead has its read call returned even if the buffer is 0.
A simple example hopefully highlighting the difference
Window1: nc -nvlp 5555 #"far nc" Window2: nc -nv 127.0.0.1 5555 #"local NC" Hi there[Enter] Hi [Ctrl+D]There[Ctrl+D][Enter] Window3: strace -p [pid of local nc] Window2: [Right arrow][Right arrow][Ctrl+D] [Ctrl+D]Uh oh[Enter]What we see is pretty much as described. From the first line, we see “Hi there\n” on the other side. For the second line, we first see "Hi " appear, then “There” then “\n”.
From the third line, in the strace we can see the sequences representing the right-arrow key, and we can see the tty driver on the far side takes those sequences and interprets them to render the cursor two characters to the right.
The fourth line is where it gets more interesting. We send the tty driver the EOF byte, and the tty driver interprets this and gives the current active tty client a 0-byte return to read() and assumes we have no more data to send. But unlike bash, nc doesn’t care about a 0-byte read and is still looking for more data (as we can see in the strace). But if we continue to type and send more data (the “Uh oh”), we can see in the strace that the tty never sends this to the nc. So, to some definition, we’re still sending data to the local nc, but the tty driver isn’t actually relaying it
I don’t get the reference. This is the first time I’ve read that claim. But I’d certainly hope people know there is a difference between End Of Line and End Of File… I mean they’re alike, they both end something. But it’s not the same thing. The article explains the details how it’s handled.
Yeah, my bad. I should have linked to the previous post: https://discuss.tchncs.de/post/32637183 (not entirely sure what’s the etiquette for linking to posts on Lemmy is).
Right, I must have scrolled past it. I think linking posts is fine. I mean they’re public and this is social media… At least I do it somewhat regularly and I’ve never had anyone complain.
I meant what’s the link to use since the same Lemmy post can be viewed through different instances and on each it has a different URL. It’s a bit user-hostile that the link gets you out of your instance (unless you’re on the same instance as author of the post).
That’s right. I don’t think there is a good way to do it. I just take whatever link is provided by the small Fediverse icon. But I don’t think it matters that much for your audience, they’re spread over several instances and it’ll be an external link for some of them, no matter what you do. I’m not sure whether we have the ambition to solve this. I don’t see anything the user could do. Either this gets handled in some way by the software, or it is how it is.
Isn’t ctrl-m the “enter” equivalent?
Yes. So is Ctrl+J actually. Ctrl+J corresponds to line feed (LF) and Ctrl+M corresponds to carriage return (CR) ASCII characters. They are typically treated the same way.
Found it in the classic The UNIX Programming Environment from 1984:
But then, this is for return, which technically isn’t “enter”, but nowadays they are sort of interpreted the same by programs?
Yeah, it’s a bit philosophical.
- In graphical applications, Ctrl+M, Ctrl+J and Return/Enter are all different things.
- In a terminal in raw mode, Ctrl+M and Return/Enter are the same thing but Ctrl+J is something different. You can for example run
bind -x '"\C-j":"echo a"'in bash and Ctrl+J will do something different. - In a terminal in canonical mode, they are all the same thing. There probably are some
sttyoptions which can change that though.
