NetBSD Problem Report #9786

Received: (qmail 24199 invoked from network); 5 Apr 2000 05:42:44 -0000
Message-Id: <200004050541.XAA02437@loop.home>
Date: Tue, 4 Apr 2000 23:41:19 -0600 (MDT)
From: swp@alumni.rice.edu
Reply-To: swp@alumni.rice.edu
To: gnats-bugs@gnats.netbsd.org
Subject: chat(8)
X-Send-Pr-Version: 3.95

>Number:         9786
>Category:       bin
>Synopsis:       Previous fix to chat(8) broke it.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 05 05:43:00 +0000 2000
>Closed-Date:    
>Last-Modified:  Sun May 25 09:50:00 +0000 2008
>Originator:     Steve Peurifoy
>Release:        1.4V
>Organization:
>Environment:
System: NetBSD loop 1.4V NetBSD 1.4V (loop) #1: Fri Mar 24 18:33:34 MST 2000 root@loop:/usr/src/sys/arch/hp300/compile/loop hp300


>Description:
	Last May a change to chat.c was committed as a fix for PR 5685.
	The change was to set the ONLCR flag for the tty device chat(8)
	was interacting with.  The problem is that this rather ad-hoc
	kludge has the potential to break any chat script that expects
	to be able to precisely control its send strings by using the
	escape sequences as documented (and in fact did break at least
	one such script).  The previous version had output postprocessing
	turned off for a reason.
>How-To-Repeat:
	Run a chat script with a send string of "foo\r\n\c" and watch
	what comes out of the tty port.  In this case it's possible to
	compensate for what the tty driver inflicts on your string (once
	you find out about it) but if instead you actually wanted to
	send "foo\n\c" you'd be out of luck.
>Fix:
	I think this change should be reverted.

Index: chat.c
===================================================================
RCS file: /cvs/src/usr.sbin/pppd/chat/chat.c,v
retrieving revision 1.1.1.4
diff -c -r1.1.1.4 chat.c
*** chat.c	1999/11/14 23:13:43	1.1.1.4
--- chat.c	2000/04/05 04:36:31
***************
*** 583,589 ****
      have_tty_parameters  = 1;

      t.c_iflag     |= IGNBRK | ISTRIP | IGNPAR;
!     t.c_oflag     |= OPOST | ONLCR;
      t.c_lflag      = 0;
      t.c_cc[VERASE] =
      t.c_cc[VKILL]  = 0;
--- 583,589 ----
      have_tty_parameters  = 1;

      t.c_iflag     |= IGNBRK | ISTRIP | IGNPAR;
!     t.c_oflag      = 0;
      t.c_lflag      = 0;
      t.c_cc[VERASE] =
      t.c_cc[VKILL]  = 0;

>Release-Note:
>Audit-Trail:
From: David Holland <dholland@eecs.harvard.edu>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/9786: Previous fix to chat(8) broke it.
Date: Sat, 19 Jan 2008 16:38:33 -0500

 The code in question is still in chat(8) (although the source is now
 src/dist/pppd/chat/chat.c) and I find the logic in this PR persuasive,
 whereas the circumstances of the original commit (-r1.16 of the old
 chat.c, discussed in PR 5685) are somewhat suspect and suggest to me a
 tty driver bug.

 Does anyone out there still use pppd with a modem and feel like
 investigating this further?

 -- 
    - David A. Holland / dholland@eecs.harvard.edu

From: Michael van Elst <mlelstv@serpens.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/9786: Previous fix to chat(8) broke it.
Date: Sun, 25 May 2008 11:43:53 +0200

 Hi,

 the change from PR5685 is even more dubious since

 - tip worked without OPOST (ONLCR is ignored!) but the change enabled OPOST.
 - ONLCR only modifes the output of '\n', but chat doesn't send '\n' in that
   session.

 If there is any change in behaviour it comes from OPOST and not from ONLCR.

 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

>Unformatted:

Home	PR Database Search