rusty (01/14/83)
given the following command line cmd & stty tostop & wait ; fg ``cmd'' produces output and takes a minute or so to produce it, therefore the stty exits successfully before it. i would expect that csh would run both of the 1st two commands in the background and do the wait until ``cmd'' tries to do some output whereupon it would be stopped and then the fg would be executed and you'd get attached to ``cmd''. this is not what happens. as an example try the above and use the following shell script for ``cmd'': #! /bin/sh sleep 10 echo "hello, world" be sure to do an ``stty -tostop'' beforehand in case you have tostop set.
thomas (01/17/83)
It looks to me like the problem is not a bug in the csh, but that you're trying to do it slightly wrong. Here is my analysis of the events. =Spencer Script started on Sun Jan 16 21:07:39 1983 1 gr> set echo # so we can see what is happening 2 gr> (sleep 10 ; echo "hi") & stty tostop & wait ; fg # try the command [1] 3153 sleep 10 # first part of command 1 [2] 3155 # stty command (don't know why it isn't echoed wait # and a wait [2] + Stopped (tty output) stty tostop # stty does several ioctl calls, # apparently at least one happens # after the TOSTOP [1] + Stopped (tty output) ( sleep 10; echo "hi" ) # we expect this to stop fg # and the fg command executes ( sleep 10; echo "hi" ) # [1] continues and finishes echo hi hi 3 gr> jobs # BUT, there is a stty left there jobs # Not a bug - wait waits for ALL [2] + Stopped (tty output) stty tostop # children to finish, since [1] # stopped last, it was continued by fg 4 gr> %2 # get rid of the extra stty stty tostop 5 gr> stty -tostop # and set -tostop # This is the correct way to do it - # Don't run the stty backgrounded 6 gr> (sleep 10 ; echo "hi") & stty tostop ; wait ; fg [1] 3160 sleep 10 # cmd 1 starts stty tostop # stty runs to completion wait # csh waits [1] + Stopped (tty output) ( sleep 10; echo "hi" ) #[1] stops fg # is continued ( sleep 10; echo "hi" ) echo hi # and completes hi 7 gr> exit script done on Sun Jan 16 21:09:43 1983
sibley (01/18/83)
The article from utah-gr!thomas contained a reasonable analysis of the "stty tostop" problem, but missed at least one important point. A little experimentation shows that most stty commands stop when run in background, regardless of the setting of "tostop". I guess this is a feature, so background jobs can't affect your terminal, similar to the way they can't change the environment. At least this is consistent. Try stty tabs & Whether you have tabs or tostop set or not, this stops with the (tty output) message. This is a little confusing, as there isn't really any output. It's just unwilling to change things unless it's in foreground. Since stty calls are equivalent to ioctl's, I guess ioctl would show the same behavior. I can't find any of this in the manual, however. Dave Sibley Department of Mathematics Penn State University psuvax!sibley
mjb (01/18/83)
>From sdcarl.4253:
given the following command line
cmd & stty tostop & wait ; fg
``cmd'' produces output and takes a minute
or so to produce it, therefore the stty
exits successfully before it.
WRONG. The man pages for "jobs" clearly states:
If a process which is not in the process group of the terminal
attempts to change the terminals mode, the process group of that
process is sent a SIGTTOU signal, causing the process group to stop.
Csh fires up background processes with their own process groups, thus the
stty will not be in the process group of the terminal and will be stopped
before setting tostop. ``cmd'' is therefore never stopped.
Not afraid to read the documentation,
mike braca {decvax,vax135}!brunix!mjb