In message <199407222139.QAA00545@s069.infonet.net>, Dave Burgess writes:
> I think I have found an oddness that I had not seen before either in
> the system or in the mailing list...
> 
> When I fire up kermit, the systems waits for something to happen right
> before it connects to the /dev/tty02 port.  The sure fire way to make
> it connect is to ^Z and then 'fg' the job.  When the 'fg' restarts the
> process, the port is connected and the SLIP connection script (user-id
> stuff notwithstanding) to establish my SLIP connection runs.
> 
> I have tried several other signals (^C for example) and they all have
> the same effect.  Whatever event kermit seems to be waiting for is
> suddenly satisfied and the program jaunts of merrily connecting my to
> the outside world.  
> 
> I find it just the least bit spooky.

It would have helped if you mentioned the state of the com port (e.g.
stty output) and the settings you use in kermit.
I guess your port has clocal cleared, and kermit is configured to
assume that there is no carrier on that port present. In this case,
kermit hangs in ttopen(), line 1597 (at least in edit 189):

1595: #ifndef NOCOTFMC /* = NO Close(Open()) To Force Mode Change */
1596: /* Reportedly lets uugetty grab the device in SCO UNIX 3.2 / XENIX 2.3 */
1597: 	close( priv_opn(ttname, O_RDWR) ); /* Magic to force change. */
1598: #endif /* NOCOTFMC */

priv_opn() calls open(), and this blocks, waiting for carrier.

Just compile kermit with -DNOCOTFMC, and your problem should go
away. At least, it did for me :)


Ciao,
Hannes
-- 
Hans-Christoph Deeken | hannes@flinx.{RoBIN.de,hotb.sub.org} (home)
Paul-Wagner-Str. 58   | deeken@iti.informatik.th-darmstadt.de (university)
64285 Darmstadt       | IRC: Glenlivet            | "Tuuut." -- Karate Kid 2

------------------------------------------------------------------------------