Re: tramp

[Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> >       tramp: Looking for pattern ^\(([^) 	]*)\|[^> 	]*[>]\)\s-*
>> 
>> This looks like your shell-prompt-pattern.  Is it?
>
> Ah, perhaps it is.  Since shell-prompt-pattern is basically not used anymore,
> I had forgotten that I had one.  However, in this case it's still clearly
> wrong, since it's not _my_ shell that's being started, but root's.

Right.

>> At this point, Tramp is again waiting for shell-prompt-pattern, and
>> this shell prompt does not match the regexp above.
>> 
>> It used to be that Tramp tried to grok some common shell prompts in
>> addition to shell-prompt-pattern.  Maybe I should re-add this feature.
>
> I think it _definitely_ should match common shell prompts, as
> `shell-prompt-pattern' is quite likely to be wrong, for the reasons I gave
> above:

Okay, 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.

>  (1) It's not used by shell-mode anymore, so it's going to suffer bit-rot.

Ah.  Hm.  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.

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?

(After Tramp has ascertained that it is indeed talking to the remote
shell, it sets the shell prompt to a special value and then uses
that, and this mechanism works well.  I haven't heard any complaints,
yet, at least :-)

>  (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?

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.

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