On Tue, 24 Jul 2001, Ed Avis wrote:
> Could TRAMP include support for fsh
> <http://www.lysator.liu.se/fsh/>? This is an rsh-compatible command
> that reuses an ssh tunnel. In other words, once the ssh connection
> has been established, it is left open for subsequent commands rather
> than setting up a new connection each time. Also included is fcp,
> which is analogous to scp.
>
> Since fsh and fcp are drop-in replacements (once installed) for ssh
> and scp, all that's needed should be some new entries in
> tramp-methods.
>
> Please cc: any replies to me since I do not read this list.
Yes, it should be sufficient to just add some entries to
tramp-methods. Maybe nobody has tried this, however, because Tramp
can already work quite well without fsh. There are two ways to use
Tramp: using an out-of-band method, `scp' (or a similar program) is
invoked for each file transfer. But if you use an inline method, it
just invokes `ssh' once and then keeps the connection open and
transfers the files through that connection.
Anyhow, here is something for fsh/fcp:
(require 'tramp)
(add-to-list 'tramp-methods
("fcp" (tramp-connection-function tramp-open-connection-rsh)
(tramp-rsh-program "fsh")
(tramp-rcp-program "fcp")
(tramp-remote-sh "/bin/sh")
(tramp-rsh-args ("-e" "none"))
(tramp-rcp-args nil)
(tramp-rcp-keep-date-arg "-p")
(tramp-su-program nil)
(tramp-su-args nil)
(tramp-encoding-command nil)
(tramp-decoding-command nil)
(tramp-encoding-function nil)
(tramp-decoding-function nil)
(tramp-telnet-program nil)
(tramp-telnet-args nil)))
It is untested. Does it work? As you can see, I just copied and
pasted it from the default value and replaced ssh with fsh and scp
with fcp.
I guess it makes no sense to use fsh rather than ssh for inline
methods: both would open a connection only once, and in this case fsh
has no advantage.
> BTW: one more suggestion - could the default method be to have TRAMP
> try several different connection methods in turn until it finds one
> that works (and remember it for subsequent connections to the same
> host)? That would make it more usable 'out of the box'. I imagine
> the order of preference would be to try the more secure methods
> first, and among equally secure methods try the fastest first.
I have intentionally refrained from doing this, since Tramp already
tries so many things on the remote end. I didn't want to add another
level of complexity to this.
Another complication is that it is not clear which method is faster.
Another complication is that it might not be easy to figure out which
methods work. For example, whether rcp asks for a password can only
be tested by running it, first.
One thing which might be useful, however, is to unify the inline
methods. Tramp could look for something that does base64 encoding,
and if it doesn't find anything, it could fall back to something that
does uuencode.
But still... for example, Tramp might find a way to do base64 encoding
if you add the right (nonstandard) directory to tramp-remote-path
(where mimencode can be found). Right now, the user is immediately
alerted to this. With your change, the user might wonder why Tramp is
behaving strangely (the reason being that it uses a strange transfer
method).
kai
--
~/.signature: No such file or directory
