Programming

It's nothing to do with what function you use because your terminal device is configured to echo and line-buffer. The echoing and buffering isn't happening anywhere in your code -- it happens in the operating system itself. You have to tell it not to do that.

But stdio isn't prepared to read from a raw terminal, since they act rather strange. So, once you change the terminal settings, you need to read from it with a low-level read().

@jim: I used your exact code to test it before I implemented it and I couldn't get it to work.

@corona: So if it has to do with my terminal settings what setting do I need to change?

I haven't tried your code, but this line bothers me:

Code:

term.c_cc[VMIN]=0;

Isn't that supposed to be 1 for what you're looking to do? Maybe your OS handles the 0 case differently from those systems that jim_mcnamara tested it with.

There is also no need for select().

Well, echo, of course, that must be turned off. And the minimum read size has to be set to zero. And to put it out of canon mode, which line buffers and such, into the raw mode which does what you want.

Or, in a nutshell: All the settings Jim changes.

Strictly speaking, there's not. But since the terminal doesn't block in raw mode like this, it's way better than a CPU-sucking infinite read() loop. Other alternatives, like poll(), aren't portable.

I can't perfectly explain why, but 0 seems to work better than 1. with 1 it seems to block mysteriously.

So you're saying 1 is the correct setting, right? We do want to block, reading one character at the time, and that's just normal behavior for noncanonical terminals unless you're using O_NONBLOCK.

The select() kludge is unneeded if you set c_cc[VMIN] properly.

Nowhere in the original question does the OP mention any wishes for timeouts of any sort.

The terminal I'm using is pretty simple. I took a course in C/Unix last quarter and I'm using the terminal they had us use, which I'm sure is probably very basic since the class is aimed at engineers rather than computer science/computer programming majors. It's called SSH Secure Shell. Do you have any recommendations on maybe a more advanced terminal? Free?

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.