Allow for passing Ctrl-C and don't mix stderr with stdout

[Ole Tange]

I have been losing my mind over this problem, so any ideas are welcome.

When running non-interactive jobs on remote machines, I want output to
stderr and to stdout to remain separate in two streams just as if they
were run locally. I also want jobs running remotely to die when I
press Ctrl-C just as if they were run locally.

At first glance these do not seem to be mutual exclusive, but when you
get further into the details it seems they more or less are.

"ssh example.com ls no_such_file" will print "ls: no_such_file: No
such file or directory" on stderr.

"ssh -tt example.com sleep 1000" will run sleep on the remote machine.
Pressing Ctrl-C will kill sleep.

But:

"ssh -tt example.com ls no_such_file" will print "ls: no_such_file: No
such file or directory" on STDOUT.

"ssh example.com sleep 1000" will run sleep on the remote machine.
Pressing Ctrl-C will NOT kill sleep.

So 'ssh -tt' will do the right thing for Ctrl-C, but the wrong thing
for stderr, and 'ssh' will do the right thing for stderr but the wrong
thing for Ctrl-C.

I have asked on StackExchange:
http://unix.stackexchange.com/questions/134139/stderr-over-ssh-t and
the solution there:

* works for: suse, debian, mandriva, scosysv, ubuntu, unixware,
redhat, raspberrypi.
* does not kill remote job for: tru64, hurd, miros, freebsd, openbsd,
netbsd, qnx, dragonfly
* blocks for: solaris, centos(sometimes works), openindiana, irix, aix, hpux

Is there a way where I can avoid mixing stderr with stdout and have
remote jobs killed when I press Ctrl-C (as 'ssh -tt' does)?

Background

GNU Parallel uses 'ssh -tt' to propagate Ctrl+C. This makes it
possible to kill remotely running jobs. But data sent to STDERR should
continue to go to STDERR at the receiving end.


/Ole