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

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

[Simon Allfrey]

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 have been hacking into shell.el/comint.el to try to pass a literal
TAB(remotely bound to completion) to the remote shell and read the
resulting completion. However, even after attempting to remove all
output-filter-functions I get nothing back.

Any chance of some code which will replace the current input line
with the remote shell's idea of it's completion?
Tanks,
simon.allfrey@epfl.ch

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

[Kai Großjohann]

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?

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

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

[Simon]

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?

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

[Kai Großjohann]

simon.allfrey@epfl.ch (Simon) writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (KaiGroßjohann) writes:
>
>> 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,

Hm.  Do you have Perl on the remote machine?  In principle, there is
code in Tramp that uses Perl for base64 encoding.  But I think the
code does not currently work.  So if you know Perl and would be
willing to help correct that Perl code, then we could both be happy:
Tramp would work for you and I could fix a Tramp bug.

>    * `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.

Hm.  Is there anything at all you can do on the remote host with
uudecode so that it writes to stdout?  Maybe it would work to make a
hack like replacing the filename with /tmp/foo and then doing
uudecode and then "cat /tmp/foo".

What (remote) system is this?

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

Command completion, instead of just filename completion?  Hm.  Whee.
I'm not sure what to do there.

I wonder if anyone has tried to send the current (partial) command to
the remote shell, followed by TAB, and to then analyze the output.  I
think this was recently discussed on one of the Emacs groups, but the
output wasn't seen.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)