[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tramp (2.0.29); why is scp not used and why is the perl-ish mime-enc
Re: tramp (2.0.29); why is scp not used and why is the perl-ish mime-encode preferred over mimencode
Wed, 12 Feb 2003 21:08:13 +0100
Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50
> 1.) why is scp not used,
> although it's available:
Err. I have no idea. Are you using an out-of-band method or an
> 2.) Why is the perl-ish mime-encode being transmitted and used,
> although there is the "true" mimencode:
> And it's located in the same directory,
> where tramp finds "GNU ls" through tramp-remote-path.
Ayee. That's because of an inconsistency in Tramp. Tramp explicitly
searches tramp-remote-path to find the `ls' executable to use. But
Tramp just uses the encoding/decoding commands verbatim, instead of
also searching for them in tramp-remote-path.
You could work around this problem by adding an entry to
`tramp-coding-commands' that refers to the programs using the right
I'm not sure what to do. Some of the commands mentioned in
tramp-coding-commands are in fact shell functions; their
implementation is sent to the remote host in the connection setup
phase. So it is not trivial to change it; one must excercise care.
I'm not sure what to think about the `ls' issue. I'm sure that I did
things this way because some systems had more than one `ls' program
and the first one was not necessarily the right one to use for
Tramp. (Is it possible that /usr/5bin/ls was necessary on SunOS 4?
Or /usr/ucb/ls on a SysV-ish system? I don't remember.) Maybe this
problem of having multiple implementations is not so serious for the
other commands used in tramp-coding-commands, so the same workaround
is not necessary.
A turnip curses Elvis