Date: Fri, 26 Oct 2001 13:30:52 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Mark Murray <mark@grondar.za> Cc: John Baldwin <jhb@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cu(1) (Was: Re: cvs commit: src/etc/mtree BSD.var.dist) Message-ID: <Pine.NEB.3.96L.1011026132852.88508F-100000@fledge.watson.org> In-Reply-To: <200110261659.f9QGxXY47978@grimreaper.grondar.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 26 Oct 2001, Mark Murray wrote: > > > If we are keeping uucp junk around for cu(1), why is cu(1) not a port? > > > Alternatively, what are the desirable features of cu(1) that tip(1) really > > > needs to be able to do? > > > > I can just type 'cu -l /dev/cuaa0 -s 115200' w/o needing to setup an entry in > > /etc/remote. i.e., laziness. :) > > Aaaaah! The thot plickens :-) > > Do you have a problem with cu being a port and not in the base system? > > (ie, a port that gives you _just_ cu with no other UUCP crap?) Since I use cu on a daily basis for serial console stuff, port testing for pccards, etc, I'd really like to keep it [or a morally equivilent program] in the base system. For the reasons John specified, I've always found tip to be a pain to use, and unless there's a good reason not to, keeping cu instead would keep me happy. For the obvious reasons, I wouldn't mind if the UUCP baggage were trimmed. However, what's the status of our serial port locking mechanisms in light of recent further UUCP directory trimmage? Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011026132852.88508F-100000>