curses/ioctl 4.0.3 (only) problem ??

eric.edberg elel at cbnewsd.att.com
Tue Apr 10 00:21:14 AEST 1990


I use a established curses library of menu routines to display data on the
screen.  At some point in time the user may want to execute a program
dependent on a menu item picked.

The library is supplied with a function:   call(program), that would end
curses, fork a child and exec the program.  It would wait() on it's
completion and restore the environment to its previous state.  Please note
that this routing has worked reliably for many years.

Very general pseudo-code:

	main_program()
	{
		start_curses();
		savetty();
		create_windows();
		l=get_menu_pick();
		call(program[l]);
		redraw_screens()
		get_more_input()
	}
	call(p)
	{
		resetty();
		end_curses();
		if(pid=fork(()==0)
		{
			execl(program)
			err()
		}
		if(pid==-1) err();
		code=wait(&status);
		start_curses();
		savetty();
		create_windows();
		return(highbyte(status));
	}


This procedure always work fine on all SV hosts and all Sun hosts running
3.X versions of Unix.

When I compile it on a 4.0.3 host problems are encountered when the
library (call functions) appears to re-initialize the the curses screens
and return to redrawing data on the screen.

The function that recreates the windows appears to execute successfully,
but I cannot draw any data on the screen.  It appears that the screen has
just died.  My program is caught in a loop reading invalid data
(characters) from the screen.  It appears that the ch=getch() function is
failing due to a closed/invalid input tty/port.  When I try to redraw data
on the screen, nothing appears.   The same problem occures when I execute
the program on a vt100 terminal.

Again, this program has worked on many architectures for many years.  It
only failes on 4.0.3!

I know that the tty/io/curses stuff was changed  on 4.0.3 and need some
help if anyone has also come across this problem.

I am not sure if it is a curses prolem or an ioctl problem.  Any
suggestions??

eric edberg
att!ihlpa!elel
(708)713-5231



More information about the Comp.sys.sun mailing list