[comp.unix.questions] Curses problem

blh@nbires.nbi.com (Boyd Hays) (09/21/88)

Help,
    I am trying to write a driver program to control a curses-based
    application over a pty-tty connection.  The setup looks like:

	MY Code					Curses Application
	1. find a free tty/pty pair
	2. put the found tty side of
	   the tty/pty in cbreak mode.
	3. fork
	   3a. 	child side exec's curses	Starts running here
	       	program.
	   3b. 	parent reads output of		Applications sends out
		child from pty side and		initialization messages
		waits for child to quit		eventually reaching some
		sending out initiazation	steady-state.
		messages.
		parent issues writes over
		the pty to control the child
		application.
		SUBSEQUENT READS DO NOT SEE	I suspect it never sees
		ANY ACTIONS ON THE PART OF	any of the characters I
		THE CHILD.			am sending it, so it sits
						there idle.
    
    So, the problem would appear that the forked process is not seeing
    any of the characters I am sending it. I can however read just fine
    from the pty.  I am certain the receiving tty is in cbreak mode (I
    modified stty to allow me to look at its tty characteristics). I've
    tried writing large amounts of data to the remote process thinking
    my writes were being buffered but to no avail. I've tried not re-
    programming the tty and letting curses take care of it during its
    initialization, that doesn't work either.

    This problem is present regardless of the curses application I run.
    My application, vi, and a 10 line curses program all have the same
    symptoms.

    This code is running, or I should say not running, on an Integrated 
    Solutions 4.3 BSD system.  Does anyone out there have a clue as to
    what the problem could be.  Thanks in advance.

    Boyd Hays 	(blh@nbires.nbi.com)
    303/444-5710

-- 
blh@nbires.nbi.com

ray@madnix.UUCP (Ray P. Hill) (12/13/88)

Curses Experts:

	Why does the following curses code sample produce a different output
	on UNIX systems?

	Some machines produce and map both windows while others map both
	windows to the same location on the screen. Our VAX, Sun3, 386i, and
	286 XENIX machines work correctly (2 windows), while 386 XENIX and
	Pyramid (AT&T universe) work incorrectly (1 window).

	|-----|			|-----|
	|     |			|     |
	|  |-----| = Working	|     | = Broken
	|  |     |		|     |
	|--|     |		|-----|
 	   |     |
  	   |-----|

	Can someone show me how to make this code sample work?

						Thanks.
						Ray Hill
						ray@madnix
---- Cut Here ----
echo x - test.c
cat > "test.c" << '//E*O*F test.c//'
/*  COMPILE WITH:
 *  cc -O -o test test.c -lcurses -ltermcap
 */

#include	<curses.h>

main()
  {
  WINDOW	*win;

  initscr();
  win = newwin(10, 10, 0, 0);
  box(win, '|', '-');
  overwrite(win, stdscr);
  win = newwin(10, 10, 5, 5);
  box(win, '|', '-');
  overwrite(win, stdscr);
  move(16, 0);
  refresh();
  endwin();
  }
//E*O*F test.c//

exit 0
-- 
UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!ray
                                 {decvax|att}!      !
                               {uunet|ncoast}!marque!

dean@violet.berkeley.edu (Dean Pentcheff) (12/14/88)

In article <263@madnix.UUCP> ray@madnix.UUCP (Ray P. Hill) writes:
>	Why does the following curses code sample produce a different output
>	on UNIX systems?
>	Some machines produce and map both windows while others map both
>	windows to the same location on the screen. Our VAX, Sun3, 386i, and
>	286 XENIX machines work correctly (2 windows), while 386 XENIX and
>	Pyramid (AT&T universe) work incorrectly (1 window).
>
> [ code including overwrite()... ]

A couple of weeks ago I spent some time testing overwrite()
extensively.  I checked it on BSD 4.3 running on a VAX, AT&T System
V/R2 (Microport SV/AT 2.2.1L) running on an AT clone, and MS-DOS (using
Bjorn Larsson's PCurses and the Turbo C 1.5 compiler).  I found that
overwrite() was broken (though with subtle differences) on both BSD and
System V.  It worked correctly only on PCurses.  I got a note from a
fellow at AT&T who said that they knew about the bug in earlier System
Vs, and the problem was completely corrected in the forthcoming System
V release (V4, is it?).

Anyway, I concluded that overwrite() (and probably overlay()) are too
commonly broken to allow portability.  This is a sucky answer, but:
your code is right, the library is bugged, and I think you should avoid
using overwrite().

-Dean

Dean Pentcheff        dean@violet.berkeley.edu
----------------------------------------------
As an adolescent I aspired to lasting fame, I craved factual certainty, and I
thirsted for a meaningful vision of human life - so I became a scientist.  This
is like becoming an archbishop so you can meet girls.               M. Cartmill

andre@targon.UUCP (andre) (12/14/88)

In article <263@madnix.UUCP> ray@madnix.UUCP (Ray P. Hill) writes:
>	Why does the following curses code sample produce a different output
>	on UNIX systems?
Because some implementations are not correct, the berkeley curses manual
speaks of overwrite at the same x y coordinates, but the terminfo curses
manual just speaks of overwriting. On the system I am on, a Pyramid only
the row information is used. The 'broken' picture becomes:
|------|
|      |
|------|
|      |
|      |
|------|

>/*  COMPILE WITH:
> *  cc -O -o test test.c -lcurses -ltermcap
> */
Making the name 'test' was a joke, right?

The way I 'solved' the wrong behaviour of the pyramid curses was to
make a subwin on the screen I wanted to overwrite with the same dimensions
& the same position as the source window. This will work on all curses'es

    WINDOW *w, *subw;
    initscr();
    w = newwin(10, 10, 5, 5);
    subw = subwin(stdscr, 10, 10, 5, 5);
    box(w, 0, 0);
    overwrite(w, subw);

Or, if you know the size and position of all windows in your application
you can use a function like:

    my_overwrite(src, dest, lines, cols, orgy, orgx)
    WINDOW *src, *dest;
    int lines, cols, orgy, orgx);
    {
	    WINDOW *sub = subwin(dest, lines, cols, orgy, orgx);

	    if (sub)
	    {
		overwrite(src, sub);
		delwin(sub);
	    }
    }

By the way, beware of overwrite with curscr.

	Hope this helps, Andre

-- 
~----~ |m    AAA         DDDD  It's not the kill, but the thrill of the chase.
~|d1|~@--   AA AAvv   vvDD  DD        Segment registers are for worms.
~----~  &  AAAAAAAvv vvDD  DD
~~~~~~ -- AAA   AAAvvvDDDDDD        Andre van Dalen, uunet!mcvax!targon!andre

achor805@pirates.armstrong.edu (Lois Achord) (06/01/91)

In article <1991May31.161614.361@bhpcpd.kembla.oz.au> dif@bhpcpd.kembla.oz.au (David Faulkner) writes:
>I am an inexperienced C programmer, and have written a curses based 
>front and back end for an existing Fortran program. When I call the
>Fortran subroutines, I set nocbreak() and echo(), but no input required
>by the Fortran routines will echo to the screen. How can I get around
>this problem.
>
>Thanks
>       -dif-
>-- 
>Dave Faulkner, Research Officer                     (dif@bhpcpd.kembla.oz.au)
>BHP Coated Products Division, Research and Technology Centre
>Port Kembla, New South Wales, Australia.


I have a similar problem at work.  I am trying to use a curses program
to accept a one character response and send it to a Fortran program.

My problem is this: the curses routine (endwin, I think) I found in the
manuals clears the screen after exiting the C routine.. thereby erasing
all of the stuff printed on the screen.  It doesn't even wait for the
character to be typed.. 


I think the other routines are initscr and getchar, but I'm not positive,
I'm not at work with the code in front of me.

Any help from you curses gurus will be greatly appreciated...

Lois Achord	achor805@pirates.armstrong.edu

dif@bhpcpd.kembla.oz.au (David Faulkner) (06/01/91)

I am an inexperienced C programmer, and have written a curses based 
front and back end for an existing Fortran program. When I call the
Fortran subroutines, I set nocbreak() and echo(), but no input required
by the Fortran routines will echo to the screen. How can I get around
this problem.

Thanks
       -dif-
-- 
Dave Faulkner, Research Officer                     (dif@bhpcpd.kembla.oz.au)
BHP Coated Products Division, Research and Technology Centre
Port Kembla, New South Wales, Australia.