Re: tramp

[Miles Bader <miles@lsi.nec.co.jp>]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Tramp now has its own variable, tramp-shell-prompt-pattern, that users
> can set.  The default value is the same as the default value for
> shell-prompt-pattern, so it should match the prompts that your examples
> showed.

I just tried tramp /su:localhost:/etc again today, and it works!

Startup's a bit slow though; it'd be nice if all the file-downloading
&c could be omitted on a local connection (presumably that couldn't be
the default, but it could be configurable).  Actually it would be nice
to be able to say, for _any_ specific host/user/method combo `I've
already installed tools x&y, here's where you can find them.  Yet
another job for the whizzy per-method/machine/user configuration alist.
[I guess there are probably variables for this; I've not checked.]

> shell-mode just assumes that everything on the last line is a prompt,
> right?  Hm.  But I think it's not possible for Tramp to assume something
> similar.

Probably not.

> It is vital for Tramp to wait until it sees a shell prompt before
> sending something to the remote shell.  If you send input to the
> remote shell too early, things go wrong in a quite horrible way
> (depending on the remote login program that you are using).
> 
> But maybe waiting for the shell prompt is not the right thing to do.
> What could Tramp do instead?

I don't know; is simply waiting for _some_ output too optimistic?

> >  (2) In many cases, a shell started by tramp will be in a `different
> >      context' than a normal user-shell, and so will have a different
> >      prompt anyway.
> >
> > Probably it ought to be possible to modify this on a
> > per-connection-type and per-machine basis (but presumably that will be
> > handled by the whizzy config mechanism that will added to address
> > other problems, right?).
> 
> Is it really necessary to modify the regexp like this?  Isn't it
> enough for the user to set one value which covers all alternatives?

Perhaps, but I think for me, it's more natural to think in little bits,
for concrete cases, rather than trying to cover all cases with one mondo
regexp.

It's also possible that there will in fact be conflicts, though I haven't
any personal experience of any (e.g., host X uses a shell prompt that
actually matches some other non-shell prompt login output on host Y).

> If possible, I would like to avoid having too many parameters that
> are based on method or machine.
> 
> But I'm having similar arguments about tramp-remote-path.  It's also
> just one variable, and people are requesting me to make it configurable
> on a per-host basis.  But I think it is sufficient to have one global
> value which contains all the directories on all the hosts.

I think this is a much more dangerous assumption than in the prompt case,
since what is a trusted directory on one host may not be on another.

Since there definitely are parameters which will have to be host/method
specific, and that you're better off simply making a general mechanism by
which _all_ parameters can be set on a host/method specific manner.

E.g., just an alist containing machine/method/user specs, and variables
and values, which tramp will run down and do
  (set (make-local-variable VAR) val)
inside the tramp work buffer.  Then the code can use simple variables,
but the user still gets max flexibility where needed.

An example format might be:

  ((SPEC (VAR . VAL) ...) ...)

where SPEC is either a regexp matching the hostname, or a tuple like
(HOST USER METHOD) where the components are regexps or nil (meaning
match anything).

That's what I want.

[I haven't looked at tramp's code though, so perhaps the above is not a
workable solution.]

Thanks,

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.