On 17 Oct 1999, Kai Großjohann <[EMAIL PROTECTED]>
wrote:
> Daniel Pittman <[EMAIL PROTECTED]> writes:
>
>> Yes, those are indeed annoying. Maybe I will have a look and see if I
>> can find out something about why they are so painful. Having no money
>> this month gives me *so* much free time for hacking. :/
>
> Well, at first I had the problem of making sure that the output
> arrives in the right order. (Else the end-of-output marker would not
> be at the beginning of a line.) But that seems to be pretty much
> solved. Now, the problems are with the initial connection setup.
>
> One problem is with SSH2 -- I send `echo hello' to the remote end
> rather soon, but if an SSH2 shell sees input too soon, it gets
> confused. One has to hit RET after a while to make it work again.
This one is not something that I can look at; no SSH2. Well, not right
now, anyway. Sadly SSH is starting to seem less and less reliable to me
the more I work here - I spent an hour or so fixing a TCP deadlock in my
backup script last night caused by SSH. :(
> The other problem is with the login methods which start an interactive
> shell: I have to wait for the shell to come up, and that sometimes
> seems to fail, or maybe I'm giving up the waiting too early.
>
> I now think that the right approach is to just look for the shell
> prompt for the second problem. And I'm going to do away with the
> non-interactive login method (rcp-open-connection-rsh). Instead, I
> just `exec /bin/sh' when finished, and then I set the prompt for the
> shell to `/////' or something. I think that will do something useful.
That sounds reasonable - but might it be worth using a unique string
(say, process id or something) for each connection - just to reduce the
odds that something run remotely will spit out that string?
I have seen a number of (ugly as heck) C++ files where sections were
broken up by a line of '////////' all the way across...
Daniel
--
No sight is more provocative of awe than is the night sky.
-- Llewelyn Powys