bet@ORION.MC.DUKE.EDU (Bennett Todd) (07/05/89)
It appears that bash isn't ignoring TSTP. Since in general there isn't any parent to continue, it is a fairly severe hang when bash goes to sleep (requires sending it a CONT from another shell). -Bennett bet@orion.mc.duke.edu P.S. Mail is really flaky around here -- could you please (attempt to) ACK this note? Thanks!
bfox@AUREL.CALTECH.EDU (Brian Fox) (07/06/89)
It appears that bash isn't ignoring TSTP. Since in general there isn't any parent to continue, it is a fairly severe hang when bash goes to sleep (requires sending it a CONT from another shell). -Bennett bet@orion.mc.duke.edu P.S. Mail is really flaky around here -- could you please (attempt to) ACK this note? Thanks! Please be specific, and explain where you have had a problem with this? In a login shell, Bash ignore stop signals. In a non-login interactive shell, Bash does not ignore stop signals. I haven't had a problem with this. Brian
bet@ORION.MC.DUKE.EDU (Bennett Todd) (07/06/89)
(Thanks for sending to me directly; I think I oughta subscribe to bug-bash. I'm gonna try bug-bash-request@ai.mit.edu; if that isn't the correct address could someone please mail me? Thanks.) Sorry for the lack of detail. Sun-3 (/50, /60, plus servers) running SunOS 3.5. I just checked, and sure enough the login shell (which is down underneath the window manager on the raw console) does in fact ignore TSTP. All the shells users actually use, at least around here, are windows. That means that yes, you can go to another window, run a ps or top or whatever, find the stopped shell, and manually kill it with a CONT. That kind of procedure isn't the sort of thing that it is nice to tell users they are stuck with. The C shells seem to ignore TSTP whenever they are interactive, which seems to me a sounder approach. Perhaps there is something wrong with our configuration here that is at fault, but I filed the report because I saw bash windows locking on ^Z typed inadvertantly at the shell, which wasn't a problem with the C-shell varients we've used. The behavior was identical under SunOS 3.5's suntools, under X11R3 (both the console window and those started up by uwm), and under MGR. Lest I sound ungrateful I should mention (I should have in the first note now that I think about it) that I think Bash is terrific, I switched over to it within moments of compiling it (which went perfectly, without a hitch). I am seriously planning on trying to convert our users over. Thanks for the great tool! -Bennett bet@orion.mc.duke.edu
bfox@AUREL.CALTECH.EDU (Brian Fox) (07/06/89)
Date: Wed, 5 Jul 89 15:56:29 EDT From: bet@orion.mc.duke.edu (Bennett Todd) fault, but I filed the report because I saw bash windows locking on ^Z typed inadvertantly at the shell, which wasn't a problem with the C-shell varients we've used. The behavior was identical under SunOS 3.5's suntools, under X11R3 (both the console window and those started up by uwm), and under MGR. There was a flaw in the implementation of signal handling in readline.c. I have since fixed the flaw, but I have also made readline and history a library, which means that the relavant files reside in a different directory, and a new file is in bash, and lots of changes in organization have taken place. New release in a couple of days. Brian