new big in pcomm 1.1

[Dan Mercer]

	Sorry Emmet,  but I found another bug.

	I noticed that sometimes if I hit the delete key when
	forked to the shell that when I returned to my remote
	session inpute from the remote line wasn't being picked up.
	However,  if I hit another hot key function,  I would then
	get a flood of input.  I usually hung up the connection
	and tried again.  I finally remapped (using stty) DEL
	so I didn't have the problem.  This was under 1.0.

	After compiling 1.1,  I checked to see if the same problem
	existed and it did.  I finally had time to hack around
	and found the problem,  but I still don't have a complete
	solution and feel it would be pretty arrogant to offer
	one.  So here's the problem in a nutshell:

	Pcomm forks and exec's pcomm_input.  Pcomm_input catches
	interrupt using it to determine whether to suspend input.
	When the user wants to fork to the shell,  pcomm parent
	forks and execs.  Pcomm child does a signal(SIGINT,SIG_DFL)
	while pcomm parent sets up to ignore the delete key.
	However,  when the user uses the delete key,  pcomm_input
	catches the interrupt signal and unsuspends input.

	When the user leaves the shell,  pcomm parent sends
	interrupt to pcomm_input to unsuspend input,  but actually
	suspends input.  Of course,  the problem is intermittent
	because if an even number of deletes are hit,  the 
	input routine is returned to the proper state.

	Why is pcomm_input receiving the interrupt from another child
	process of its parent?  Because the parent,  both children
	and the original user shell are all members of the same
	process group,  and /dev/tty is its controlling terminal.
	Hacking around,  I was able to bypass the problem by
	(in terminal.c right after the fork but prior to the exec)
	fclose-ing stdin and then calling setpgrp to set
	pcomm_input up as the leader of its own process group.
	When the port is opened,  it then becomes the controlling
	terminal.

	The problem with this hack (and why I'm more than happy to
	leave the fix to you) is that hangup will no longer come
	from /dev/tty hanging up,  but from the unlikely event
	the port line gets hung up.

	I submitted it to this group for two reasons:
	I am totally at a loss at how to mail anything (anybody
	who can mail me any doco on using mail would be greatly
	appreciated).  I don't even have amn files to help me out
	(our usenet box is woefully underpowered).  My management
	is also not sympathetic to my being on the net (though
	they love the free software).

	My other reason is the hope that some wizard out there
	with a better knowledge of process groups might be able to come
	to the rescue.

	My congratulations on a great product.  Considering it's
	size, its capability,  and the fun and  glory of dealing
	with curses(foiled again) its a remarkable achievement.
	Its allowed us to cancel a commercial product that had
	a much harder user interface and far more bugs,  to the
	point where it was unusable for our user base (computers,
	we don't need no stinking computers).

	Oops,  one other bug.  By opening the port directly,  instead
	of using the System V dial command,  one other problem pops up
	during long sessions.  Dial sets an alarm to touch the lock
	file at 45 minute (I think) intervals.  This is because a
	uucp cron task will clean up and remove the lock file if
	it's more than 1 hour old,  largely because uucp and cu
	do such a lousy job of cleaning up their mistakes.

	And here's one for the net:  does anyone know how to
	keep curses from insuring that the terminal is not
	in input mode on startup?  I use an ADDS viewpoint 90
	for my primary terminal.  Input mode is a toggle - the
	same escape sequence turns on and off input mode.
	Whenever curses comes up,  boom,  I'm stuck in input
	mode (it's not even constant,  since the exit input mode 
	sequence can come out more than once).
	My bypass is to keep separate terminfo entries for
	curses and non-curses applications.  Any help

	Dan Mercer
	NCR Comten