Subject: Re: HEADS UP: tip/cu changes
To: None <current-users@netbsd.org>
From: Igor Sobrado <igor@string1.ciencias.uniovi.es>
List: current-users
Date: 04/11/2006 16:27:46
Hello.
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,
Igor.