I am in the process of replacing our present version of cu (which is
part of Taylor UUCP) with the cu frontend we've always had in usr.bin/tip
but never used.  There will be some user-visible changes, most notably:

1) I have changed a number of defaults in tip.  In particular, we now
   default to 9600bps and 8n1 instead of 1200bps and 7e1 (of course, in
   the absence of an /etc/remote file, tip doesn't do anything, so this
   change may not be particularly visible).

2) The new version of 'cu' will support many common, but not all, options
   from the Taylor 'cu'.  In particular, it supports some of the long
   options, but not all (in particular, --system is not supported).

3) We no longer use a compiled-in table of speeds.  Instead, we will
   accept any speed supported by the underlying tty device.  Because
   some of our serial drivers are buggy in this regard (they will allow
   any speed to be set, but some may not work), this may give slightly
   surprising results, particularly with USB serial adapters.

4) I have removed support for all dialers except "Hayes".  If anyone is
   actually using any other dialer I will add it back; let me know.

5) I have turned off support for the ACU log by default; it requires the
   executable to be setuid and nobody seems to be using it anyway.  If
   anyone is actually using it I will consider converting it to use
   syslog.

6) I have added '~+' as an alias for '~C' for Taylor compatibility.

7) I have turned off "raisechar" by default; if anyone is using it, that
   person is insane (but can always turn it back on via /etc/remote,
   tiprc, or ~s).

In addition, some of the ~ command syntax is different from what Taylor
cu users may expect (it is more like historical cu, or tip).  The manual
page for tip documents it already, though it will take some time for me
to catch the manual page up to my other changes.

I would love feedback from anyone who wants to test this version of tip
as cu: just change its name to 'cu' and see how it works for you.

One known problem is that the "hardwareflow" variable does not seem to
actually enable/disable CRTSCTS.  I think yamt may have missed a couple
of lines of code while importing that change from OpenBSD; one of us
will fix it soon.

Many (though not all) of these changes came from OpenBSD.

-- 
  Thor Lancelot Simon	                                     tls@rek.tjls.com

  "We cannot usually in social life pursue a single value or a single moral
   aim, untroubled by the need to compromise with others."      - H.L.A. Hart