As for the else, I suppose I could add a simple "exit(0)" in an else there but I never expect the server socket to close. It is bad practice to not handle it if it does though so thanks for pointing it out.

wrt sysread, are you talking about the regex that looks for : at the begining of the buffer read? Are you saying that maybe this will fail if sysread reads 1 and 1/2 lines and then the second half of the second line in the next call? I can see your point if that is what you are talking about. Is there another way of reading from a socket that will ensure at least a complete line with each read? Possibly a slurp style read (<$ircsock>)?

I think what you really want to do (since your ircsocket might lose connection for any number of reasons like an irc server restart), is to just reopen the socket. I.e. something like this:

if ($fh == $ircsock) {
  ...
  if (sysread($ircsock, $ircdata, 512)) {
     ...
  } else {
    $sel->remove($ircsock);
    close($ircsock);
    ...reopen $ircsock...
    ...add $ircsock to $sel...
  }
[download]

As for the sysread issue, I'm talking not just about that regex but also the rest of them. For example when you have your /^JOIN\s*\#(\S+)/ regex. If the sysread returns something like JOIN #test\nJOIN #blah, your code will silently ignore the second command.

A slurpy read is one way to solve it, and for IRC this will probably work fine since the IRC protocol is linebased.

In general, it may be better to do something like:

my $clientdata = "";

while (1) {
  #-- Add the new data at the end of the existing one
  sysread $fh, $clientdata, 512, length $ircdata;

  #-- See if we have a full line we can process
  while ($fh =~ s/^(.*?)\r?\n//) {
  my $line = $1;

  ... do your per-line regex stuff here...
  }
}
[download]

This means of course that in your case you need to keep track of $clientdata on a per-filehandle basis (have something like an %clientdata hash keyed on the filehandle). And of course you wouldn't have the while (1) in your code.

Update: A few more ways in which your current sysread code can go wrong: if the server sends a >512 byte line, you will send this to your clients as two lines with a newline inbetween, because you unconditionally add a \n after your print to the clients. In this particular case you're probably better off just removing the chomp($ircdata) and print the string to the clients as-is.

Your current code also silently drops server messages to clients that can't currently receive them. This may be what you intended of course.

One last issue I forgot is your use of \n to terminate lines you send to the server (i.e. in your NAMES or TOPIC commands). The IRC protocol specifies that all lines need to be termiated with \015\012. If you're running your code on windows you're in luck since that's exactly what \n generates, but on other platforms this may not be the case so it's safer to explicitely use \015\012 (or some suitable constant of course).