Since I'm using Linux, why is a carriage return required?

(Note: most of this is guesswork regarding *nix -- not my FOE -- but its nothing to do with threads)

In the days of old, the linefeed character just moved to the next line; an carriage return was required to move to the start of the line. (Think about how manual typewriters operate. If you ever seen one.)

To the best of my knowledge, most *nix consoles only require LF to cause them to perform both operations, but that's a reinterpretation of the purpose, and probably only operates when the console is operating in 'cooked' mode.

My guess is that

the issue only presents itself when the SSH/tcpdump line is included.

the command you are issuing is switching the terminal into 'raw' (or 'ultra-raw') mode and failing to reset it when it ends. Hence, thereafter, the LF is only moving to the next line, and is failing to return to the left hand edge.

Perhaps the thing to do is use Term::ReadKey::ReadMode() to control/restore the settings after the command ends.

That makes sense. I'm no way any expert on Linux Terminals and this is a weird issue I haven't seen before. Once I get back to work on Wednesday I'll troubleshoot this some more. Thank you again.

One other question: My ultimate goal is to use pipe opens in the threads if possible. Currently I'm capturing only 10 packets into those scalars. I would much rather prefer to use the pipe opens (so that data is continuously streamed from the various servers and printed out in real time). I had some trouble trying to implement that however. What would you recommend to perform such a task? Basically the code was the same, but the SSH line was replaced with a pipe open to the SSH/tcpdump process, then a while loop in each thread, that would print data if it was seen.

I can see that being difficult, as I've read in a few places that pipe opens aren't supported in Perl threads. Still, it would be much more preferable to find a way to stream the data continuously and not just capture 10 packets at a time, having to run the entire thing in some loop that constantly creates new SSH connections.

I can see that being difficult, as I've read in a few places that pipe opens aren't supported in Perl threads.

Hm. Where? I've never heard of, nor encountered, any problems with piped-opens in threads. (unless its a *nix thing I've never seen reported.)

Try this which will happily run tens of concurrent piped-open commands on Windows:

#! perl -slw
use strict;
use threads;
use Thread::Queue;

our $T //= 10;
our $N //= 1000;

my $Q = new Thread::Queue;

async{
    my $tid = threads->tid;

    open my $cmd, '-|', 'count.pl ' . int( rand $N ) or die $!;

    $Q->enqueue( "$tid:$_" ) while defined ( $_ = <$cmd> );
    $Q->enqueue( "$tid:done\n" );
    $Q->enqueue( undef );
}->detach for 1 .. $T;

for( 1 .. $T ) {
    while( $_ = $Q->dequeue ) {
        printf "%s", $_;
    }
}

__END__
##This is count.pl
#! perl -slw
use strict;

$|++;
my $i = $ARGV[0] // 30;

print --$i while $i and sleep 1;
[download]

Eg

C:\test>t-popen -T=10 -N=10
8:done
1:2
2:4
4:5
3:5
6:4
5:0
5:done
7:0
7:done
9:8
10:4
1:1
2:3
4:4
3:4
6:3
9:7
10:3
1:0
1:done
2:2
3:3
4:3
6:2
9:6
10:2
2:1
4:2
3:2
6:1
9:5
10:1
2:0
2:done
4:1
3:1
6:0
6:done
9:4
10:0
10:done
4:0
3:0
4:done
3:done
9:3
9:2
9:1
9:0
9:done
[download]

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Good idea I'll definitely do that.