> Does that mean that, by default, fgets() blocks until the user enters a newline
Yes. By default, terminals operate in canonical mode. I/O does not happen at all until the user inputs a full line. Until the user hits Enter, the characters on the screen are just sitting there in the terminal's memory while the application's read system call is blocking on the terminal's file descriptor. The terminal does not write the data until the line is complete.
> and, before they do, it lets them edit the line buffer using the backspace, CTRL+W and CTRL+U shortcuts?
Provided that "it" refers to the terminal, then yes. Normally it's the terminal itself which allows you to edit the line you are typing on. This is also provided by the default canonical mode. Even the fact that letters show up on the line when you type is a terminal feature called echoing. So are things like backspace, delete, Ctrl+C for SIGINT, Ctrl+D for EOF.
Line and text editors just turn off all of this stuff. They place the terminal in raw mode where everything you type is sent immediately to the application where it is handled immediately. A wide variety of everyday programs do stuff like this. For example, password prompts simply turn off echoing to hide the characters.
Even the traditional Unix line ending \n is actually a feature of terminals. To the terminal, \n just moves the cursor down one line, \r is also needed to go back to the beginning of the line. The true line ending is therefore \r\n. The terminal just happens to invisibly turn \n into \r\n. This too can be disabled.
> The terminal just happens to invisibly turn \n into \r\n.
No, it was actually done by the Unixen itself, in the part of the kernel that handled ttys: it convert '\n' to '\r\n' on writes to ttys, and '\r' to '\n' on reads from ttys. Linux only recently have moved this functionality out into the user-land layer.
Hmmm, I could swear I have read about moving line discipline out of the kernel in some LWN article but apparently no, it never happened (although it probably should've, there is no much reason to perform mapping of NL to CR-NL in the privilleged mode). Maybe I've confused it with what happened on the Windows side of things? They moved almost all of the console infrastructure out of the kernel recently and into the user space, and that definitely has happened.
I suspect Linux actually can't move it to user space. It would break binary compatibility with all user space code that sets OPOST via the ioctl. They can't hide it in a libc either.
Yes. By default, terminals operate in canonical mode. I/O does not happen at all until the user inputs a full line. Until the user hits Enter, the characters on the screen are just sitting there in the terminal's memory while the application's read system call is blocking on the terminal's file descriptor. The terminal does not write the data until the line is complete.
> and, before they do, it lets them edit the line buffer using the backspace, CTRL+W and CTRL+U shortcuts?
Provided that "it" refers to the terminal, then yes. Normally it's the terminal itself which allows you to edit the line you are typing on. This is also provided by the default canonical mode. Even the fact that letters show up on the line when you type is a terminal feature called echoing. So are things like backspace, delete, Ctrl+C for SIGINT, Ctrl+D for EOF.
Line and text editors just turn off all of this stuff. They place the terminal in raw mode where everything you type is sent immediately to the application where it is handled immediately. A wide variety of everyday programs do stuff like this. For example, password prompts simply turn off echoing to hide the characters.
Even the traditional Unix line ending \n is actually a feature of terminals. To the terminal, \n just moves the cursor down one line, \r is also needed to go back to the beginning of the line. The true line ending is therefore \r\n. The terminal just happens to invisibly turn \n into \r\n. This too can be disabled.