Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ORION.MC.DUKE.EDU!bet
From: bet@ORION.MC.DUKE.EDU (Bennett Todd)
Newsgroups: gnu.bash.bug
Subject: Re: Bash 1.01 Job Control handling buglet
Message-ID: <8907051956.AA08610@orion>
Date: 5 Jul 89 19:56:29 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 27

(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