I have been losing my mind over this problem, so any ideas are welcome. When running jobs on remote machines, we want output to stderr and to stdout to remain separate in two streams just as if they were run locally. We also want jobs running remotely to die when we press Ctrl-C.
At first glance these do not seem to be mutual exclusive, but when you get further into the details 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 I see several ways forwards: * Implement the StackExhange solution: Great for Linux, sucks for *BSD, horrible for Solaris and HPUX. * Make an option to activate the StackExhange solution (sort of the opposite of --ctrlc). * Leave as is: stderr and stdout are mixed for remote jobs. Ideal would be to find a way to let ssh know that we want both Ctrl-C and separate stderr/stdout. If your friends know a way to do that, please let me know. /Ole
