the <> operator is a buffered operation. If there are 3 newlines within the received data, your program would have received up to the first, but the remaining data could well have been read off the socket by the buffering logic. The select would hang,

Precisely. Excellent point; a particular pitfall to <$sock> not clearly pointed out before.

I don't think that you have a choice about using non-blocking sockets. If you are receiving variable-length data, I can't recall a way to look at how much is in the socket buffer before reading. You can either read a char at a time, and keep checking via select (not very pretty), or switch to non-blocking.

Wrong. If you use sysread (or recv) with select then there is no problem reading variable-length data. If you don't read enough to drain the input already available, then select will tell you that there is more to be read. If you ask for more data than is available, then sysread will return only what is available to you without hanging.

Of course, if you are hoping to process the input only as complete lines, then this adds a layer of complexity where you may have to buffer up partial lines read and only process them the next time select tells you that there is data to be read.

However, the typical archecture for using select is to have an object for each socket which means that buffering up partial lines in this object is no big deal.