From owner-freebsd-bugs@FreeBSD.ORG  Thu Nov 13 21:12:29 2003
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Delivered-To: freebsd-bugs@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5BC1716A4CE
	for <freebsd-bugs@FreeBSD.org>; Thu, 13 Nov 2003 21:12:29 -0800 (PST)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 67D6F43FE1
	for <freebsd-bugs@FreeBSD.org>; Thu, 13 Nov 2003 21:12:27 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246])
	by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id QAA08106;
	Fri, 14 Nov 2003 16:12:04 +1100
Date: Fri, 14 Nov 2003 16:12:02 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Eugene Grosbein <eugen@kuzbass.ru>
In-Reply-To: <200311140350.hAE3oL30030201@freefall.freebsd.org>
Message-ID: <20031114155242.J6133@gamplex.bde.org>
References: <200311140350.hAE3oL30030201@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: freebsd-bugs@FreeBSD.org
Subject: Re: bin/54141: wrong behavour of cu(1)
X-BeenThere: freebsd-bugs@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Bug reports <freebsd-bugs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bugs>
List-Post: <mailto:freebsd-bugs@freebsd.org>
List-Help: <mailto:freebsd-bugs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2003 05:12:29 -0000

On Thu, 13 Nov 2003, Eugene Grosbein wrote:

>  There is a strange workaroung for this problem: start "cu -l cuaa0"
>  then switch to another terminal, do "stty -crtscts </dev/cuaa0"
>  and cu starts to work as expected (for this run only).

Is this with the old cu (from Taylor uucp) or the current cu (which
is tip warmed over)?  I think the old cu has an option for setting
crtscts, so it is barely reasonable for it to clobber the default
if you don't use this option.  tip/cu is too stupid to support
crtscts, but it programs the termios c_cflag correctly (doesn't
attempt to clobber bits that it doesn't understand), so it uses
the system default.  OTOH, Taylor cu uses the system default for
the speed but tip/cu uses its builtin default.  The system default
for crtscts is off unless you reprogram it using the initial state
port.  Apparently you are using the old cu and it defaults to setting
crtscts (and this default changed?).

>  It seems that cu(1) does not respect prior command
>  "stty -crtscts </dev/cuaia0" anymore. Or it might be a kernel bug
>  as preliminary "stty -crtscts </dev/cuala0" does not help too.

To lock a flag off, it must be turned off in the initial state port
(before the port is opened) and locked off by turning it (strictly,
its lock bit) _on_ in the lock state port.

Bruce