in reply to Re^5: Threads Printing Issue - Output Mangled / Term Crashing
in thread Threads Printing Issue - Output Mangled / Term Crashing

OK great suggestion I should have thought of this sooner. It was the only option I changed in the SSH line and that was most likely causing the issue. I just find it weird that simply putting that output in a variable can mess up your local prompt.
  • Comment on Re^6: Threads Printing Issue - Output Mangled / Term Crashing

Replies are listed 'Best First'.
Re^7: Threads Printing Issue - Output Mangled / Term Crashing
by soonix (Chancellor) on Apr 15, 2014 at 06:22 UTC

    It is not "putting something in a variable" that changed your local prompt, i.e. not something that ssh sent to its output, but something that ssh did to its (and per the -t Option: your) terminal

    ... just like changing the time (e.g. via `date -s ...`) affects the whole System, regardless of whether you assign that command's output to a variable or print it directly (or discard it completely)

    In programming this is called a side effect, although it is often the main reason for doing it :-)

      Yeah that's true. I was looking at it the wrong way. I think I have a pretty good idea of what the issue is with this new information, thanks.
        strace may show something interesting. For instance:
        strace -o /tmp/out -f perl -e 'print `ssh localhost -tt -l root tcpdum +p -c10 -nntttt`'

        On my computer that works pretty fine, and I don't see any tty access. Maybe just updating the ssh client could solve your problem.

        update: Ah, I can see what's happening:

        ssh -tt ... reads the terminal flags from STDIN (ioctl(0, TCGETS, ...)), sets new ones (ioctl(0, TCSETSW,, ...)) and runs the remote command. Then, upon exit, it restores the original flags.

        The issue is that with multiple ssh processes running in parallel, some of them may read the already modified flags and so later, reset STDIN to an incorrect state.

        An easy workaround is to wrap the part of the code where the threads are started and then joined with an extra couple of TCGETS/TCSETSW ioctl calls. Another option is to just redirect STDIN from /dev/null.

        update 2: The following program works correctly on my computer:

        use strict; use warnings; use threads; use threads::shared; my @threads; my @servers = (('localhost') x 100); my $lock:shared; foreach my $server (@servers) { chomp $server; push (@threads, threads->create (\&dumpServer, $server)); } foreach (@threads) { $_->join(); } sub dumpServer { my $server = shift; my $net = `ssh -l root -tt $server '/usr/sbin/tcpdump -c10 -nntttt 2 +>&1' </dev/null`; lock($lock); print "TEST - $server\n$net\n\n"; }