I would assume that since the problem only occurs when running under your "sqrsh" utility which submits remote commands, that the problem is triggered by how "sqrsh" deals with STDIN/STDOUT/STDERR.

In my own parallel execution tools (which are probably similar to sqrsh), I ended up emulating a TTY for the remote command to execute under - it was the only way to solve all of the esoteric issues one hits with various remote commands.

If you'd like to try to upgrade sqrsh to work around the whole general case (instead of hacking up check_cvs.pl to work around sqrsh), see the forkptycmd() function I've documented in a perlmonk comment here. It was developed with the help of the monks here, and seems to solve the problem for me. my $fh = forkptycmd('rsh machine123 somecommand'); returns a filehandle you can use to read/write from the executing rsh process, and makes that process believe it is writing to a real terminal.

Also since it forks off subprocesses for commands and returns filehandles for them, you can, for instance, do things like:

foreach my $host (@hosts) {
   $cmdfh->{$host} = forkptycmd("rsh $host $command");
}
[download]

And then use select(), poll(), or other types of nonblocking methods to watch all the filehandles in parallel. This way you don't end up waiting on one to finish before you issue the next - true parallel remote execution.

Beware at larger numbers of hosts there may be other issues to solve as well (like, if you're using rsh as root, you can only do a small number (~ 120-ish) in parallel before you run out of priveleged ports to issue the rshs from).