Francis Moreau <[email protected]> writes:
> Cool although I don't know when it will reach an emacs version which
> I'll be able to grab...
Emacs 23.2 is roughly planned for March. But you know, it's ready when
it's ready when it's ready ...
>> Looks like it is more complicate, it is because encoding/decoding seem
>> to fail. I'll analyze.
>>
>> For the time being, could you try to use "scp" instead of "ssh" when
>> accessing this device?
>
> Well, I can't use scp/ssh since there's no sshd on the remote target.
> I can only use the telnet method.
Oops, I've mixed this with your previous problem.
Your current problem is that Tramp has chosen an inappropriate encoding
mechanism on your remote host:
> 18:22:43.801802 tramp-send-command (6) # perl -e 'binmode STDIN; binmode
> STDOUT; print pack(q{u*}, join q{}, <>)' < /etc/passwd 2>/dev/null; echo
> tramp_exit_status $?
> 18:22:43.853588 tramp-wait-for-regexp (6) #
>
> tramp_exit_status 127
> ///7918cfc694ee6398d9db1b7991544b9a#$
> 18:22:43.854092 tramp-barf-unless-okay (1) # File error: Encoding remote file
> failed
I'm a little bit concerned about the ^H chars, they shouldn't be there.
On busybox, there shall be uuencode/uudecode commands (at least my
BusyBox v1.10.2 has them). Could you, please, check, whether they are on
your device?
Unfortunately, your trace was not complete this time, so I could not
check why Tramp has refused to use uuencode/uudecode. Could you, please,
apply "M-x tramp-cleanup-all-connections", and rerun the test? I would
like to see the trace then, as usual.
Best regards, Michael.
_______________________________________________
Tramp-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/tramp-devel
