mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) (10/11/88)
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