Re: ctrl-c gnu parallel and sshlogin

[Ole Tange]

I think is it solved. My god it is UGLY:

Instead of:

your_preprocessing | ssh server "your_command" | your_postprocessing

it will be implemented like:

your_preprocessing |
   uuencode a | ssh -tt -oLogLevel=quiet server "stty isig -echoctl
-echo ; uudecode -o - |
your_command |
   uuencode a" | uudecode -o - |
your_postprocessing

Example:

seq 10000 | gzip |
   uuencode a | ssh -tt -oLogLevel=quiet server "stty isig -echoctl
-echo ; uudecode -o - |
zcat |sort -r|bzip2 |
   uuencode a" | uudecode -o - |
bzcat >foo

It also requires people to have installed 'uuencode' and 'uudecode'. I
tried using perl -ne 'print pack("u",$_)' but that does not work. It
seems uudecode closes the input when it received 'end' and does not
wait for end-of-file.

If you want this implemented, you should speak up now. It will not be
default because of the depencency on uuencode.


/Ole


On Thu, Jun 7, 2012 at 7:41 AM, Nameless Numerologist
<thenamelessnumerologist@gmail.com> wrote:
> Hi Ole,
>
>   It's been working for me.
>   Revert away.
>
> Thanks,
> NN
>
>
> On Mon, Jun 4, 2012 at 1:42 PM, Ole Tange <tange@gnu.org> wrote:
>>
>> On Mon, Jun 4, 2012 at 12:57 AM, Ole Tange <tange@gnu.org> wrote:
>> > On Thu, May 31, 2012 at 11:32 AM, Ole Tange <tange@gnu.org> wrote:
>> >> On Wed, May 30, 2012 at 4:15 AM, Nameless Numerologist
>> >
>> >>>   I was wondering if I'm missing some obvious flag when it comes to
>> >>> the
>> >>> persistence of sshlogin jobs following ctrl-c.
>> >>
>> >> Yeah, the CTRL-C bothered me, too.
>> >
>> > I think I got it solved now.
>> >
>> > Please test the newest git version.
>>
>> I have now tested. The solution has some issues:
>>
>> * Transferring of files does not work. Or rather: It requires the old
>> ssh command for the rsync. So by introducing a special ssh (internal)
>> command for the transferring this can be made to work.
>>
>> * Output from commands are \r\n separated instead of \n. This is fine
>> if the output is going on the screen, but disastrous if the output is
>> a binary stream (think output from 'gzip'). Also the output of
>> 'parallel echo ::: a' and 'parallel -S localhost echo ::: a' will be
>> binary different.
>>
>> In other words: I will have to roll back the change unless someone can
>> come up with a solution to the second problem.
>>
>> /Ole
>> --
>> Have you ordered your GNU Parallel merchandise?
>> https://www.gnu.org/software/parallel/merchandise.html
>
>