bin/54141: wrong behavour of cu(1)

Bruce Evans bde at zeta.org.au
Thu Nov 13 21:12:29 PST 2003


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


More information about the freebsd-bugs mailing list