tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tramp and NT-Emacs with plink


From: Jonathan Epstein
Subject: Re: Tramp and NT-Emacs with plink
Date: Thu, 12 Sep 2002 14:01:21 -0400

It looks as though tramp_decode is failing; here's the output, having hit C-g 
near the end ... here's the end of the (truncated) debug buffer:

$ ( uuencode xxx </dev/null >/dev/null 2>/dev/null; echo tramp_exit_status $? )
tramp_exit_status 0
# Checking remote decoding command `uudecode -o -' for sanity
$ ( echo xyzzy | uuencode xxx | uudecode -o - >/dev/null 2>/dev/null; echo 
tramp_exit_status $? )
tramp_exit_status 1
# Checking remote encoding command `uuencode xxx' for sanity
$ ( uuencode xxx </dev/null >/dev/null 2>/dev/null; echo tramp_exit_status $? )


Anyone, here's the result of the "uname", "echo xyzzy", "echo xyzzy | 
tramp_encode" and "echo xyzzy | tramp_encode | tramp_decode" commands.



/////
SunOS

/////
xyzzy

/////
eHl6enkK

/////

/////

I.e., the command "echo xyzzy | tramp_encode | tramp_decode" produces a blank 
output.


BTW, I also tried adding the following to my .emacs:

(setq tramp-encoding-command "uuencode")
(setq tramp-decoding-command "uudecode -p")

They also worked fine on the Linux systems, but still didn't work on the 
Solaris system, probably because it is hanging during the TRAMP startup test 
code.

Then I copied your Perl code into a separate file on the remote Solaris host.  
Here's what I have:

#!/bin/perl
# This script contributed by Juanma Barranquero <address@hidden>.
# Copyright (C) 2002 Free Software Foundation, Inc.
use strict;

my %trans = do {
    my $i = 0;
    map {($_, sprintf(q(%06b), $i++))}
      split //, 
q(ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/)
};

my %bytes = map {(unpack(q(B8), chr $_), chr $_)} 0 .. 255;

binmode(\*STDOUT);

# We are going to accumulate into $pending to accept any line length
# (we do not check they are <= 76 chars as the RFC says)
my $pending = q();

while (my $data = <STDIN>) {
    chomp $data;

    # If we find one or two =, we have reached the end and
    # any following data is to be discarded
    my $finished = $data =~ s/(==?).*/$1/;
    $pending .= $data;

    my $len = length($pending);
    my $chunk = substr($pending, 0, $len & ~3, q());

    # Easy method: translate from chars to (pregenerated) six-bit packets, join,
    # split in 8-bit chunks and convert back to char.
    print join q(),
      map $bytes{$_},
        ((join q(), map {$trans{$_} || q()} split //, $chunk) =~ /......../g);

    last if $finished;
}



Now, I ran this program (named tramp_decode_test.pl to avoid namespace 
conflicts), and get this on my Linux system:

  echo eHl6enkK | perl tramp_decode_test.pl
xyzzy

And this on my Solaris system:
  echo eHl6enkK | perl tramp_decode_test.pl

So, it's consistent ... we get no output on the Solaris (Perl 5.005) system.

Hmmm ... looks like some of the fancy "map" stuff may not work in Perl 5.005, 
although I haven't yet figured out exactly where it's failing.

Suggestion: it would be nice to have a way to disable some of the testing of 
the Perl code, so that things don't hang in this manner, and one can use other 
techniques such as uuencode.

Jonathan


At 06:41 PM 9/12/2002 +0200, Kai wrote:
>Jonathan Epstein <address@hidden> writes:
>
>>   Here's the end of the debug buffer:
>>
>> # Checking remote decoding command `tramp_decode' for sanity
>> $ ( echo xyzzy | tramp_encode | tramp_decode >/dev/null 2>/dev/null; echo 
>> tramp_exit_status $? )
>> tramp_exit_status 0
>> # Using remote encoding tramp_encode
>> # Using remote decoding tramp_decode
>> # Using local encoding base64-encode-region
>> # Using local decoding base64-decode-region
>> # Checking to see if encoding/decoding commands work on remote host...
>> $ echo xyzzy | tramp_encode | tramp_decode
>>
>>
>> So it looks as though it hangs on the encoding and/or decoding.  Is
>> this a known problem with older versions of Perl?  It wouldn't be a
>> big deal to upgrade Perl on that system if this is the consensus.
>
>Can you wake Emacs up at that spot with C-g?  If you can, please do
>the following:
>
>Switch to the *tramp/foo* buffer.  Now you send commands to the
>process with
>
>    M-: (process-send-string nil "COMMAND\n") RET
>
>Always remember the \n at the end.  The first command to send is
>something which just looks whether the remote end is alive:
>
>    uname
>
>If you see the answer showing up in the buffer, good.  If not, try
>sending \C-c (without \n).  Does that wake it up?
>
>Okay, now you send the following commands in order:
>
>    echo xyzzy
>    echo xyzzy | tramp_encode
>    echo xyzzy | tramp_encode | tramp_decode
>
>and report what happens after each command.
>
>Btw, it might be useful to do C-x h C-w in the *tramp/foo* buffer
>after sending each command.
>
>Also, the shell prompt looks strange: it's "/////" preceded and
>followed by a newline.  Just so that you know what you're looking at
>in the *tramp/foo* buffer.
>
>kai
>-- 
>~/.signature is: umop 3p!sdn    (Frank Nobis)
>
>
>_______________________________________________
>Tramp-devel mailing list
>address@hidden
>http://mail.freesoftware.fsf.org/mailman/listinfo/tramp-devel






reply via email to

[Prev in Thread] Current Thread [Next in Thread]