Re: tramp (2.0.29); why is scp not used and why is the perl-ish mime-encode preferred over mimencode

[Kai Großjohann]

address@hidden writes:

> 1.) why is scp not used,
> although it's available:
>
>     /usr/bin/scp

Err.  I have no idea.  Are you using an out-of-band method or an
inline method?

> 2.) Why is the perl-ish mime-encode being transmitted and used,
> although there is the "true" mimencode:
>
>     /app/idsp22/cronus1/usr/local/bin/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
path.

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.

Suggestions?
-- 
A turnip curses Elvis