Have you considered simplifying your code by using an event-loop system? For instance, can you use a simple program like this?

#!/usr/bin/perl 
use warnings;
use strict;
use Glib;

my $main_loop = Glib::MainLoop->new;

Glib::IO->add_watch (fileno 'STDIN', [qw/in/], \&watch_callback, 'STDI
+N');    

#just to show it's non blocking
my $timer1  = Glib::Timeout->add (1000, \&testcallback, undef, 1 );

$main_loop->run;

sub watch_callback {
#    print "@_\n";
    my ($fd, $condition, $fh) = @_;
    my $line = readline STDIN;
    print $line;
    #always return TRUE to continue the callback
    return 1;
}    

sub testcallback{
   print "\t\t\t".time."\n";

}
__END__
[download]

Thanks for advice, I'll consider using it as last resort. I need to avoid any extra modules and/or software on that box since that'd break vendor maintenance conditions and you know how anal they're going to be about that. Even more, if I can make this script work it'll probably run on scores of customers' boxes, making maintenance headaches unbearable...

The $select->can_read() does not block, despite what documentation says. It keeps reporting that there's something in STDIN, even if there's nothing there for sure

Define "nothing", sysread returning false? Then the handle is closed due to error (undef) or due to eof (zero). You need to handle those conditions. You are calling select (via can_read) on a handle that can't possibly ever return data.

By the way, the following is buggy:

    my $rv = $handle->sysread($bufline, 4096);
    $line .= $bufline;
    while ($rv == 4096) {
      $rv = $handle->sysread($bufline, 4096);
      $line .= $bufline unless !$rv;
    }
[download]

It'll block if there's exactly 4096 bytes waiting. Remove the loop completely. You need to rely on your select (can_read) loop. What follows in the code should just restart the select loop unless it detects that it received a full message. This requires moving your handle's buffer ($line) outside of the loop, of course. In other words, the code should follow the following pattern:

- While there are handles from which to read,
  - Wait for data to arrive.
  - Read into the handle's buf.
    -> Don't forget to handle eof and error.
  - While the buf has a full command,
    - Remove the command from the buf.
    - Process the command.
[download]

By the way,

    my $bufline = "";
    my $rv = $handle->sysread($bufline, 4096);
    $line .= $bufline;
[download]

can be written as

    my $rv = $handle->sysread($line, 4096, length($line));
[download]

I think $select->can_read() is blocking but not in the way you are expecting. can_read will return a handle when the end of file is reached as well. A feature I did not expect is that can_read will return an empty list, the blocking abruptly stopped, when a signal is caught by a signal handler. This means, after the SIGCHLD handler is executed the code execution returns from can_read with an empty list. This empty list means the end of your while loop and script.

Inside your spawn sub, when you are forking by using open you are not exiting the forked child process. The child will merrily return from the spawn sub and act as a proud new parent. Two forked processes reading the same STDIN is a recipe for bizarre behavior.

I think it would also be easier to use open to call the "script" program directly instead of forking and then calling the script with exec. If you use open to call the external program then you don't need to worry about exiting the forked process after exec.

Here is a version I messed with tonight. IPC is always interesting...

my $line = <STDIN> || q{};

You introduced bugs by moving away from sysread.

First, you've introduced buffered IO. How can the select system call know that Perl has data waiting to be read in a buffer?

Second, you're blocking until a newline is received, and that could be an indefinitely long wait.

The bug doesn't happen because perl has STDIN line-buffered. Select won't notice STDIN has read data until you press enter. This also means there will always be a newline to read for <STDIN>.

sysread will give you the unbuffered activity you expect but select will not. I think this is where you are mistaken. This means select will still be blocking until you press enter. I was able to get select to trigger on a single character by using tcsetattr to disable line-buffering (aka canonical mode) for the terminal. (code at the end of the post)

edit: Just to be clear about what this implies, this leads me to believe that line-buffering happens at a lower level than the perl interpreter. This answers your rhetorical question:

How can the select system call know that Perl has data waiting to be read in a buffer?

It is my hypothesis that the buffer you speak of happens at the system level and not inside the perl interpreter. Using stdio.h functions like getc and getline, you must read input through the terminal's internal buffer while in canonical mode. The read system call (via perl's sysread) does not use this higher-level terminal line buffer.

I have no idea how this works in windows.

#!/usr/bin/env perl

use warnings;
use strict;

use IO::Select;
use IO::Handle;
use Inline 'C';

my $select = IO::Select->new( \*STDIN );
disable_canon_mode() if @ARGV;
# Experiment by commenting out the above line and giving command-line
# arguments.

while ( 1 ) {
    $select->can_read; # block until new input
    warn "CAN_READ STDIN\n";

    my $in;
    if ( @ARGV ) {
        sysread STDIN, $in, 1;
        print "Char read: $in\n";
    }
    else {
        $in = <STDIN>;
        print "Line read: $in\n";
    }
}

__END__
__C__

#include <termios.h>

#define STDIN 0

void disable_canon_mode ()
{
    struct termios tio;

    if ( isatty( STDIN ) == 0 ) { return; }

    /* Turn off canonical mode, meaning read one char at a time.
       Set timer to 0, to wait forever. Minimum chars is 1. */

    tcgetattr( STDIN, &tio );
    tio.c_lflag &= ~ICANON;
    tio.c_cc[ VTIME ] = 0;
    tio.c_cc[ VMIN  ] = 1;
    tcsetattr( STDIN, TCSANOW, &tio );
}
[download]

A feature I did not expect is that can_read will return an empty list, the blocking abruptly stopped, when a signal is caught by a signal handler.

select returns on error, and that includes interruption by signal (EINTR).

Thanks! That was it - somehow I never expected can_read() to return with an empty handle array upon receiving a signal. But it does and it really explains everything: the silent exit and the erratic behavior and all that. Now that I got this mystery solved I'm happy and productive again. :)