From owner-freebsd-hackers  Fri May  5 05:25:54 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id FAA25233
          for hackers-outgoing; Fri, 5 May 1995 05:25:54 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA25218
          for <freebsd-hackers@freefall.cdrom.com>; Fri, 5 May 1995 05:25:28 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA20696; Fri, 5 May 1995 22:21:06 +1000
Date: Fri, 5 May 1995 22:21:06 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199505051221.WAA20696@godzilla.zeta.org.au>
To: gibbs@estienne.CS.Berkeley.EDU, nate@trout.sri.MT.net
Subject: Re: slattach!!!!!!!
Cc: daveh@CSUA.Berkeley.EDU, freebsd-hackers@freefall.cdrom.com,
        kelly@fsl.noaa.gov, rgrimes@gndrsh.aac.dev.com
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>to do a similar thing.  Some how, slattach was broken when it was 
>brought into 2.0.  I've known this for some time, but haven't had the time
>or need since I got a dedicated line to track it down.  The tty code 
>is not my area.  It would be nice if someone who knows the tty code
>and slattach could look to see what is happening when expect is used
>with slattach.  My fix for 1.1.5 was to restore the tty state from a 
>snapshot taken during startup.  The multiple forking nature of the
>current slattach makes this much for difficult, and it was a cludge 
>anyway.

I know the tty code and slattach but not expect or chat :-).  I know
of several bugs, but I think they are either unrelated to the current
problem or reduce it:

1) slattach no longer aborts on carrier drop if no -r command is given.
   Its signal handling is BAD (it does too much in the signal handler)
   and broke when the multiple forking stuff was added.

2) the 2.0 tty driver is not as POSIX conformant as the 1.1.5 driver.
   It allows the line to be reused after SIGHUPs.  The 1.1.5 driver
   required the multiple forking stuff, or with one of David's
   important patches, toggling CLOCAL like the 1.1.5 slattach does.
   (We still haven't found a good way of making control-terminal'ness
   go away at the right times.)

3) Both the 1.1.5 and the 2.0 tty (sio) driver restore the tty state
   to a programmable default at open() time, so slattach needs to
   reprogram it after every open.  I think the current slattach does
   this, although in a tangled way (after a SIGHUP it should close
   files and start over).

Bruce