Bug 19376 - ncurses alters buffering of stdin/stdout and does not restore it.
Summary: ncurses alters buffering of stdin/stdout and does not restore it.
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 4.0-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-06-19 16:30 UTC by Larry Rosenman
Modified: 2001-06-30 04:22 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Larry Rosenman freebsd_committer freebsd_triage 2000-06-19 16:30:01 UTC
 sw-bug
Comment 1 ler 2000-07-11 20:00:53 UTC
> I rebuilt my LERBSD box with the current (7/1) ncurses.
> Please retry C-Kermit...
>
It's half fixed.  After starting and then stopping curses, input is no
longer buffered but output is still buffered.  The current working sources
are in /home/fdc/kermit.  To build a version without the 4.0-specific setbuf
hack, use:

  make clean
  make freebsd41

(I left a new "wermit" binary there too.)  On the Internet, the same
source package can be found at:

  ftp://kermit.columbia.edu/kermit/test/tar/x.tar.gz

Then to test:

  ./wermit
  C-Kermit> telnet localhost
  (log in, start Kermit, put it in server mode, escape back)
  C-Kermit> send <a-file>

This puts up the curses display.  When the transfer is done, you get the
C-Kermit> prompt back.  At this point, when you type a regular character
(such
as letter) it does not echo.  However, if you type a "wakeup" character such
as "?", you get the expected response, which shows that input is unbuffered.
If you type a command like "echo foo", the command itself doesn't echo until
you press the Return key.

So in the latest ncurses, endwin() has restored the previous buffering on
stdin, but not on stdout.

No other version of Unix, including the other *BSD's, or even pre-4.0
versions
of FreeBSD, behave this way.  Or at least *behaved* this way as of about New
Years Day.  If the same ncurses code is finding its way into new Linuxes,
etc,
then maybe they have the same problem but I haven't seen it yet, since I
haven't done a "build-all" since New Years (it takes about a week to hit
every platform).

If you could post this as a followup to:

  http://www.freebsd.org/cgi/query-pr.cgi?pr=19376

I'd appreciate it -- for some reason my browser won't let me do it.  (Also,
please include the details of your installation & ncurses version, etc.)

Thanks!

- Frank

** This is with a CVSUP as of yesterday (7/10/2000 around 20:00 GMT-0500
(US/Central))
Comment 2 ler 2000-07-14 16:21:08 UTC
There was some discussion on this, and Frank da Cruz 
has now changed Kermit to use newterm() like Solaris and
others. 

The fixes imported with 5.1 of ncurses seems to have fixed the
input side. 

This can be closed, we believe.

Larry Rosenman
Comment 3 Mike Heffner freebsd_committer freebsd_triage 2001-06-30 04:18:37 UTC
State Changed
From-To: open->closed

According to the submitters: a combination of a change to C-Kermit 
plus a new imported version of ncurses, appears to have fixed the 
problem.