Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!mark.umcp-cs@udel-relay From: mark.umcp-cs@udel-relay@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: sh and sigtstp problem. Message-ID: <3674@sri-arpa.UUCP> Date: Sun, 31-Jul-83 21:10:06 EDT Article-I.D.: sri-arpa.3674 Posted: Sun Jul 31 21:10:06 1983 Date-Received: Tue, 2-Aug-83 11:14:00 EDT Lines: 25 From: Mark WeiserI spent a few minutes looking at the csh background/foreground (sh.proc.c) with which I was already familiar, and then the sh forking code (exe.c), for which it was my first time (so my judgement may be more subject to error here). I didn't come up with a definitive answer, but looking reminded me of two things going on when a SIGTSTP occurs in a child with which the sh may be unprepared to deal. 1. There are lots of extra signals floating around, SIGCHLD for instance. It looks like this should not cause any problems since it defaults to nothing, but the 'sh' of course does nothing to prepare for it. 2. The csh (and wsh and other shell-like code using process control) ordinarily hand over the control terminal to the forground process, and then grab it back when something happens to the foreground program. Signals bouncing around go to everyone in the same process group as the control terminal, which will exclude the csh, but will include the sh (since it did nothing to put anyone in any other process group since it doesn't know about process groups). This will aggravate the problems of (1) since all the extra signals will truly by zipping around. Of course, this doesn't really explain things, but I promise I won't say "if you would only use the csh...".