Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!agate!darkstar!kithrup!sef
From: sef@kithrup.COM (Sean Eric Fagan)
Newsgroups: comp.unix.wizards
Subject: Re: POSIX bashing
Message-ID: <1991Mar30.202637.8629@kithrup.COM>
Date: 30 Mar 91 20:26:37 GMT
References: <1991Mar30.012025.28876@kithrup.COM> <25262@hydra.gatech.EDU>
Organization: Kithrup Enterprises, Ltd.
Lines: 46

In article <25262@hydra.gatech.EDU> jb107@prism.gatech.EDU (Jim Burns) writes:
>in article <1991Mar30.012025.28876@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) says:
>[Barry Shein asks if anyone has implemented POSIX job control]
>> Yes.  SCO.  kithrup (this machine) in an example of how it works.  It has
>> its problems, I will admit, but it works.
>Like what?

cu closes its filedescriptors (apparantly) when it gets an intr, line-kill,
or one or two other characters.  It then tries to open it again; however,
the tty it's trying to do this to is owned by another process group, thus it
gets SIGTTOU.  At least, that's my initial guess, based on what seems to be
happening.  I compiled up a version that just ignored the job control
signals, and it stopped hanging on me (extremely annoying, I should say).
Since I got that to work, I didn't put any more effort into looking into it.
But other people may have, so there may be an official fix; I don't know.
(I *hope* so.)

The pty driver does not allow the master side to do an TIOCGPGRP on the
slave side (as they are running in different process groups, and POSIX says
that this should not happen for normal ttys).  I found this in emacs,
incidently.  I made a kernel change to allow a new ioctl (TIOCSIG), which
sends a specified signal to the process group on the slave side of the pty.
However, it is rife with security holes, so I only used it myself.  The
folks at Berkeley did the same thing when I reported the "problem" to them,
which was where I got the idea.  rms claims, and there is some indication to
back him up on this, that pty's are an extension, thus the TIOCGPGRP ioctl
should be allowed to work.  (Note, btw, that my ioctl is better:  if you are
running an SUID process in the window, emacs cannot send any signal to it;
with my change and kernel enhancement, it can.  That, unfortunately, is the
problem; I want to think things out better before I try to get it into the
next version of the OS.)

vi used to not work with job control.  However, there is an SLS available
that fixes it (which I didn't know about, and that SLS got installed on a
machine at work, and I got very confused 8-)).

Et cetera.  Essentially, 3.2.0 had a version of job control that had no
chance of working.  3.2v2 had a first version that worked; it works well
enough for me.  3.2v3 should have a much better version.  (Yes, sco does
listen and look at the bug reports!)

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.