On Mar 14, 2013, at 9:21 AM, Ole Tange <[email protected]> wrote: > * STDIN to the process is now treated as a terminal. So --pipe with > binary data will > be quite unpredictable: E.g. ^C (ascii: 3) will send CTRL-C. > * You get 'Connection to server closed' - unless you use -o LogLevel=quiet > * On STDOUT "\n" (ascii 10) becomes "\r\n" (ascii 13 10), so binary > output on STDOUT will be messed up. > * --basefile, --transfer, --return will transfer text and not binary.
I may have found a somewhat convoluted solution to this problem: > your_preprocessing | > uuencode a | ssh -tt -oLogLevel=quiet server "stty isig -echoctl -echo ; > uudecode -o - | > your_command | > uuencode a" | uudecode -o - | > your_postprocessing I found this solution here: http://unix.stackexchange.com/questions/40023/get-ssh-to-forward-signals You could probably tweak the above command to use the parallel script to handle the encoding/decoding instead of uuencode/uudecode, since it's required to have parallel installed locally and remotely. I'm not sure how difficult this would be to implement, however.
