Thanks for the replies (and the stories ;-) ).

> > I am having a rather curious problem. Sometimes when I issue a command
> > like '<someting> | more' the more 'hangs'. It does not happen very
> > often and I can not reproduce it ;-( Non of the usual signals from the
> > keyboard will get it out [ intr/kill/susp ]. The only way is a kill -9
> > on one of the other screens (if you're multi-user).
> > 
> > When I do a stacktrace from the debugger, I see something like:
> > 
> > issignal()  [ pstat == SSTOP !? ]
> > tsleep()
> > ttysleep()
> > [....]
> > ttioctl()   [ turned out to be SETAW ]
> > [....]
> > syscall()
> 
> My guess is you're using (pd)ksh. (maybe every shell with comandline editing
> has the feature)
> There is a race condition setting up the terminal state (with ttioctl) in a 
> childprocess and setting the process group of the terminal from another child. 
> 
> One child gets a SIGTSTOP if tries to do the SETAW when the terminal doesn't
> belong to it's processgroup. (and sometimes the 2'nd child is faster and you see
> the hang. BTW. a SIGCONT should help here).
The argumentation seems pretty good. But as it's not very reproducable,
I have not yet been able to check it.
[...]
> My guess (and yes our (convex) ksh had it too, it's worse if you have more 
> than one processor in the system).
Luckily I have only one.... ;-)

Leo.