"Edward J. Sabol" <[EMAIL PROTECTED]> writes:
> [...] I think it's worth investigating whether rcp.el could work
> around it in some fashion that may minimize or eliminate the
> problem. Could rcp.el detect the tset prompt?[...]
I think that's a promising approach. rcp.el already tries to
recognize a passwd prompt, so why shouldn't it recognize a tset
prompt? Sounds meaningful. I'd need some of you to debug it, though.
I just tried "TERM='?xterm' tset" on Linux, FreeBSD and Solaris, and I
saw the following two prompts (Linux = FreeBSD):
TERM = (xterm)
Terminal type? [xterm]
(Each of the lines ends with a space.) Right. Recognizing these
seems to be simple enough. Any other prompts that you are seeing?
But what should I be sending to the remote shell (to the tset,
really)? How about `dumb RET'? I guess that's the best we can do,
right? Is that terminal type defined on all machines?
[time passes]
Right now, I'm thinking of the following approach: in
rcp-open-connection-telnet and rcp-open-connection-rsh, it waits for a
couple of responses from the remote end. To these, we just add
another case which checks for the tset prompt, and then do the right
thing.
The only downside of this is that the control flow in the functions
will become a bit more difficult. For example, in the rsh function,
the remote end could respond with any of the following three after
`rsh -l user host':
(1) Password prompt
(2) tset prompt
(3) Shell prompt
If (1), after entering the password, the following are possible:
(4) `wrong password' error message
(5) tset prompt
(6) shell prompt
If (2), we expect a shell prompt, I guess.
It might well be that we check for even more things, and then this
control flow will be getting out of hand real quick.
Do you think that it might be better to have a function which waited
for any of the above? We could have a list of things which we expect
and a generic function which waits for any of them and returns which
one was seen. After seeing some response, we remove that case from
the list and try again. The iteration is stopped if we see a shell
prompt or if there is a timeout.
Yes, that might work. Hm. Wouldn't be trivial to implement, though.
Hmpf. Oh, well...
kai
--
~/.signature: No such file or directory
