Re^3: golf challenge: one-liner netcat clone

I take back my comment about write-blocking ("I don't see a check to see how much can be written without blocking"). I forgot to factor in that non-blocking applies to writing too.

So you don't have a problem with syswrite, but you do have a problem with sysread. If the sysread would block, it'll return undef, and your program will exit prematurely.

On Linux, setting the sockets and pipes to non-blocking doesn't seem to be required at all, but I am not sure it other Unixes will perform the same.

Nonsense. Imagine if the remote end does

print while <>;
[download]

If you try reading from the socket, your program will become permanently blocked.

Comment on Re^3: golf challenge: one-liner netcat clone Select or Download Code

Replies are listed 'Best First'.
Re^4: golf challenge: one-liner netcat clone by salva (Canon) on Dec 11, 2011 at 08:57 UTC
If you try reading from the socket, your program will become permanently blocked. The `select` call takes care of that. The program only reads when there is data available and the buffer is not full.	[reply] [d/l]
Re^5: golf challenge: one-liner netcat clone by ikegami (Patriarch) on Dec 11, 2011 at 09:32 UTC
Yes, you're right, the `select` (or more precisely, the `if vec`) takes care of that. So yes, you don't need to make the read handle non-blocking because of that check. You do need to continue making the write handles non-blocking because you don't have a similar check around `syswrite`. (Note that the similar check for write handles involves checking how many bytes you can write without blocking.) Sorry, I got confused by the lack of symmetry between your reading and writing code.	[reply] [d/l] [select]