Jonathan Epstein <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
http://mail.freesoftware.fsf.org/mailman/listinfo/tramp-devel
