Subject: Re: HEADS UP: tip/cu changes
To: None <>
From: Igor Sobrado <>
List: current-users
Date: 04/11/2006 16:27:46

I will copy and paste if appropriate, as I am not subscribed to
this mailing list...

cu/tip is probably one of the most important tools for me, as I use
it to manage a lot of devices (HUBs, switches, routers and even a
PowerEdge 350 server) from my laptop.  For me, cu is a key tool
and any improvement to it is greatly welcome.

> 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).

It is very nice to see that finally the _right_ defaults will be
available in tip.  Most (all?) devices are configured by default
to 9600bps 8n1.  This change makes a lot of sense.

> 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).

Support for standard options is a requirement.  Certainly, support for
long options available in one implementation of this command is not
very important.  Not a problem at all (at least for me!).

> 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.

Is there a workaround/fix for buggy drivers?  It would be nice looking
for buggy drivers to fix them.  Will someone manage this issue?

> 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.

Are these other dialers standard?  Will be a problem supporting them?
I do not use other dialers, but it would be great supporting them if
they should be here.

> 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.

Ok, it seems right.  setuid binaries are a risk that should be avoided
if possible.

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

Well, I do not think that compatibility with Taylor is a requirement,
but it looks right, though!

> 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).

If "raisechar" was enabled by default I guess that most of us were
insane!  :-)

Seriously, I agree about turning raisechar off by default.  Uppercase
is uppercase and lowercase is lowercase these days.

> 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.

Great!  I like historical commands (that should be an authoritative
reference for current implementations of these commands).  I am sure,
the behaviour of the new cu/tip will be the right one.

> 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.

I am very interested in testing cu.  I will provide some feedback
if I find an annoying behaviour on this command.  Here, I will have
a chance to check cu in a lot of different platforms (a PowerEdge 350
running NetBSD, an HP AdvanceStack HUB, a 3Com LinkBuilder and even
the Xircom combo card on my laptop).

> 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.

Thanks!  Perhaps a diff with the OpenBSD source will help, if NetBSD
version has not changed a lot...

Best regards,