brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/04/90)
Why should a non-curses character-mode application have to catch SIGTSTP? Obviously this is a fruitful source of bugs: if, for instance, I put rn into the background and type bg a few times, it'll hang. I'm not surprised. It isn't entirely obvious how to avoid the race conditions involved in setting the tty modes correctly upon stop and restart. In pty I was able to cheat a bit---this synchronization problem actually becomes easier to solve when you have two processes. But getting the average program to work correctly with job control is too difficult. In contrast, it would be absolutely trivial to have the shell set tty modes correctly when processes stop or restart. This would clear up several conceptual problems with the current design, and would greatly simplify many programs. It would also make future enhancements much easier. Ever want to ^Z out of a program and change your stty settings? You'd just have to add a few lines to your shell. To extend this a bit: I have programs ``cbreak'' and ``char'' that do nothing but change tty modes and invoke another program, making sure to restore modes at the appropriate times. There's no reason they couldn't be built into the shell. This means that applications like vi wouldn't even have to find the terminal, let alone manipulate it. Now I can simulate all the above features with pty, but I'm not going to pretend that it's the right solution to these problems. Your shell already talks intimately with a tty. Why is it necessary to subvert it and use a pseudo-tty? Why can't it manage its own tty to provide the facilities that applications need? I hope this gives shell writers some ideas. ---Dan
tchrist@convex.COM (Tom Christiansen) (11/06/90)
I agree that this is the shell's prerogative. The (t)csh I've used for the last 5 years or so has always done pretty much the right thing with modes. That is, it restores your tty to the state it was in before calling the program. It does seem to know to do the right thing with stty changes, although I haven't looked to see how it does that. --tom
news@usenet.ins.cwru.edu (11/14/90)
In article <108290@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >The (t)csh I've used for the last 5 years or so has always >done pretty much the right thing with modes. That is, it restores >your tty to the state it was in before calling the program. It >does seem to know to do the right thing with stty changes, although >I haven't looked to see how it does that. Bash uses the exit status of commands to decide whether or not to restore the terminal modes. If a command exits successfully (that is, it does not exit with a status indicating that it was killed by a signal), bash saves the tty settings; if one exits via a signal or stops, the tty state is set back to the saved settings. This takes care of stty, for instance. For the morbidly curious, here's the code :-) if (job != NO_JOB && interactive) { if (WIFSIGNALED (child->status) || WIFSTOPPED (child->status)) set_tty_state (); else get_tty_state (); notify_and_cleanup (); } Chet -- Chet Ramey ``I die, Horatio'' Network Services Group, Case Western Reserve University chet@ins.CWRU.Edu My opinions are just those, and mine alone.