Path: utzoo!attcan!uunet!dalsqnt!rpp386!jfh From: jfh@rpp386.Dallas.TX.US (The Beach Bum) Newsgroups: comp.unix.xenix Subject: uucico stomps cu (was: Re: /usr/lib/uucp/uucico ignores LCK.. files) Summary: sounds like a different problem Message-ID: <8186@rpp386.Dallas.TX.US> Date: 22 Oct 88 00:50:07 GMT References: <171@libove.UUCP> <480@jc3b21.UUCP> <1130@lakesys.UUCP> Reply-To: jfh@rpp386.Dallas.TX.US (The Beach Bum) Organization: River Parishes Programming, Dallas TX Lines: 21 In article <1130@lakesys.UUCP> jamesd@lakesys.UUCP (James Dicke) writes: >If cu doesn't work there is one way that I know to take care of it all. I use >a script to "disable /dev/ttyxx" before entering "cu" and then I "enable >/dev/ttyxx" when finished. This prevents uucico from cutting in. I too run >286 version of Xenix (though its 2.2.3). There should be no need to do this. disable only prevents someone from logging in on a line. cu should have a LCK.. file present on the line while it is in use. uucico should see this LCK.. file prior to starting up and then NOT use the line. Assuming SCO hasn't done something completely stupid, this means that getty or no getty, uucico shouldn't be stomping on your cu session. However, it obviously is. Someone needs to find out for once and for all WHO is eating lock files. I've seen it with lines enabled and not. What gives? -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Richard Stallman: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `Gno'" UucpNet : !killer!rpp386!jfh +--------------------------------------