[EMAIL PROTECTED] 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 _______________________________________________ Tramp-devel mailing list [EMAIL PROTECTED] http://mail.nongnu.org/mailman/listinfo/tramp-devel
