Re: Tramp and NT-Emacs with plink

[Kai Großjohann]

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)