Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!paperboy!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.wizards
Subject: Re: POSIX bashing (Was Re: Retaining file permissions)
Message-ID: <16701:Mar718:49:1291@kramden.acf.nyu.edu>
Date: 7 Mar 91 18:49:12 GMT
References: <21795@yunexus.YorkU.CA> <3419@unisoft.UUCP> <1991Mar07.073936.12552@kithrup.COM>
Organization: IR
Lines: 27

In article <1991Mar07.073936.12552@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:
> On the other hand, POSIX has *not* been
> ignoring the BSD stuff; try reading the POSIX 1003.1 document, sometime, and
> see what's there (job control, symbolic links, etc.).

Ah, yes, and instead of trusting BSD to have a sufficiently powerful
job-control model, they have to adopt the strategy taken by---guess
which mutant, yep, you got it---HP/UX. They have to add sessions, and
break every single bit of BSD semantics relating to foreground
processes, background processes, orphans, etc. In the meantime they have
to add an idiotic security hole: viz., any process can send SIGCONT to
any other process in the same session.

You don't think that screen, emacs, pty, et al. should break under
POSIX? You don't think that POSIX should mandate ambiguous, unnecessary,
insecure, ridiculously complex behavior without providing even a hint in
the rationale of why that behavior is an advantage? You think that it
should be possible to pass job control across sessions or through the
network (perhaps via a TELNET option) transparently? Tough luck. You're
dealing with POSIX.

As for symbolic links, POSIX had no real support for them last I
checked. Whether this is good or bad is a matter of debate; but given
that symlinks are not supported and given that sessions are a lot less
standard than symlinks, it's crazy that sessions are supported.

---Dan