Re: how to persuade shell/ssh mode to use remote dynamic completion.

[Simon <simon.allfrey@epfl.ch>]

Kai.Grossjohann@CS.Uni-Dortmund.DE (KaiGroßjohann) writes:

> simon.allfrey@epfl.ch (Simon Allfrey) writes:
> 
> > Most machines I connect to will only accept secure connections.
> > Under ssh remote directory tracking (via tramp/ssh), while possible
> > can be very slow. In the case of gateway scenario where the remote
> > machines do not support the inline tramp methods, directory tracking
> > becomes impossible. Thus I look to the remote shell to support
> > command/filename completion but I want to avoid if at all possible
> > using the unfriendly term mode.
> 
> I understand the "slow" part.  But I don't understand the "gateway
> scenario" part -- if you can log in to the machine and get a shell,
> then you should be able to use Tramp, no?

Since we need to go through a gateway a multihop method would be needed:

   * `multi' -- base64 encoding with `mimencode'

mimencode is not supported on the most remote machine and,

   * `multiu' -- use commands `uuencode' and `uudecode'

falls foul of:

   * The uuencode method does not always work.

     Due to the design of TRAMP, the encoding and decoding programs
     need to read from stdin and write to stdout.  On some systems,
     `uudecode -o -' will read stdin and write the decoded file to
     stdout, on other systems `uudecode -p' does the same thing.  But
     some systems have uudecode implementations which cannot do this at
     all--it is not possible to call these uudecode implementations
     with suitable parameters so that they write to stdout.

Even if I provided mimencode on the most remote machine, permitting
 use tramp, would the problem of command completion not remain?