Kai Großjohann
Tue, 24 Jul 2001 07:26:46 -0700
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