Having to change the terminal settings to get the behavior you want has nothing to do with your terminal client. Any terminal login you make, be it ssh, telnet, a hardwired local console, or even a serial port plugged into the machine, will behave much the same way as far as your program is concerned. That's the entire point of having the kernel manage them: It handles the raw I/O itself, and emulates any other low-level behavior necessary to make them communicate the same way as far as a program can see.

By default you get blocking mode with echo for the convenience of your program, since it's way more predictable, not to mention efficient when doing bulk data transfers. If you want raw mode, you change the kernel's terminal settings to get it.

---------- Post updated at 09:50 AM ---------- Previous update was at 09:35 AM ----------

No. By block mysteriously, I mean, block on more than one character even when vmin=1. I wasn't able to get "proper" behavior as you describe it, and don't want to give someone "compliant" yet broken code. You're only assuming that. The ability to detect when keystrokes are not happening is useful, why deny it to them?

Even assuming you're right, we want it to block at one character, no more. I couldn't get a terminal to honor that. It may not be portable either.

select() on the other hand can be trusted. It's also flexible enough to give us both options -- blocking, and timeouts, without changing the terminal settings further.

select() is not a kludge. It's a very efficient way to use a file descriptor. It also means getting the behavior you want without having to fight the the hugely complex and baroque terminal option structure. But it's handy to give them that option.