greywolf@unisoft.UUCP (The Grey Wolf) (03/07/91)
<21795@yunexus.YorkU.CA> by oz@yunexus.yorku.ca (Ozan Yigit)
& In article <see ref> jik@athena.mit.edu (Jonathan I. Kamens) writes:
&
& > ... one thing I consider broken about POSIX is that there's no
& >st_blocks field in its stat structure; more generally, there is no standard
& >way in POSIX to find out how much space a file actually occupies on the disk
& > ...
&
& Interesting consideration, though I fail to see why this amounts to POSIX
& being broken. I take ``broken'' to mean internally inconsistent, or simply
& erroneous, and instead you present your views on something that is not a
& part of the standard [along with many other things] and is yet to be shown
& indispensible within the its scope. If a strong argument could be made for
& such a thing, that would make POSIX incomplete, [which may, as often
& happens with other standards, be completed via implementation agreements
& or other supplements] but not necessarily broken.
Incompleteness, in many ways, is congruent to brokenness. "Well, in the
future, we want it to deal with that problem, but for now it doesn't ad-
dress it." is synonymous with "Well, it's broken."
I think that POSIX is an attempt at an implementation of a bare-bones OS.
There are too many things there which are simply done wrong. I agree with
Jon on this one.
Of course, one could argue that a standard should not try to define too
much...but I think POSIX purposely decided to look more like System V and
ignore all the interesting bits that made BSD better. Why, I'm not sure.
It's truly a pity that System V has more marketing clout; BSD is just SO
much more usable.
&
& Let me ask again: what is it that you know to be broken?
&
See above. Incompleteness ,', Brokenness.
& oz
& ---
& We only know ... what we know, and | Internet: oz@nexus.yorku.ca
& that is very little. -- Dan Rather | UUCP: utzoo/utai!yunexus!oz
--
# On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying
# to invoke ninth-level magic instead of taking the time to climb the other
# (quite essential) thirteen or fourteen levels so they can do this properly?
# ...!{uunet,ucbvax}!unisoft!greywolfsef@kithrup.COM (Sean Eric Fagan) (03/07/91)
In article <3419@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >but I think POSIX purposely decided to look more like System V and >ignore all the interesting bits that made BSD better. In a sense, yes, they did. >Why, I'm not sure. Because there was this thing called the 'SVID': the System V Interface Definition. This was the `base document' that POSIX started with; it provided a *lot* of the groundwork. 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.). The people at CSRG have, I've been told, been very successful at influencing certain people (such as the government) to require some of the options (such as job control, ENAMETOOLONG, etc.). >It's truly a pity that System V has more marketing clout; BSD is just SO >much more usable. In what way? On kithrup, I have job control, command-line editing (I use ksh), networking (still useful even though kithrup is the only machine it can connect to 8-)), and a few other nifty-keen things. I ... know of some other useful things coming out, but I can't comment on them. -- 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.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/08/91)
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
karish@mindcraft.com (Chuck Karish) (03/08/91)
In article <3419@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: ><21795@yunexus.YorkU.CA> by oz@yunexus.yorku.ca (Ozan Yigit) >& In article <see ref> jik@athena.mit.edu (Jonathan I. Kamens) writes: >& > ... one thing I consider broken about POSIX is that there's no >& >st_blocks field in its stat structure; more generally, there is no standard >& >way in POSIX to find out how much space a file actually occupies on the disk This looks like an issue of filesystem implementation that's beyond the scope of 1003.1. >Incompleteness, in many ways, is congruent to brokenness. "Well, in the >future, we want it to deal with that problem, but for now it doesn't ad- >dress it." is synonymous with "Well, it's broken." Yes, and my hammer is broken because it's not a screwdriver. There are, in fact, other groups working on different standards that bear more directly on this problem than did 1003.1. The 1003.7 (system management) committee may have something to add. >I think that POSIX is an attempt at an implementation of a bare-bones OS. >There are too many things there which are simply done wrong. I agree with >Jon on this one. POSIX.1 isn't an OS at all; it's a specification for a programming interface. It's always going to be necessary to write system-specific extensions, no matter how "complete" the standards are. For an illustration of the difference between a specification and an OS, consider the variety of operating systems that could be written to conform to the 4.3BSD manuals. It's the exception rather than the rule for a manual page to completely specify error returns. Luckily for us, the market for BSD systems has been based on the (relatively sane) performance of implementations rather than on the completeness of the specification. The SVID is similarly incomplete. Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
donn@hpfcdc.HP.COM (Donn Terry) (03/09/91)
>I think that POSIX is an attempt at an implementation of a bare-bones OS. >There are too many things there which are simply done wrong. I agree with >Jon on this one. Without taking too much umbrage, there are some flaws in this argument that show a lack of knowledge of what POSIX is: 1) POSIX is not, and never, ever ever, will be an implementation. It is an interface specification, and ONLY an interface specification. "Bare-bones" is true today, but not as a goal but just due to its relative youth. (In fact, it is so bare bones that an implementation that was solely what is in the POSIX of today would be useless; it must be extended to be a useful system: It doesn't *yet* even contain any commands. That's OK because of its goals: see (2) below.) 2) POSIX is intended to be an interface specification for *portable* applications across a broad range of systems. That is not the same as *all* applications, or even the same as *all useful* applications. Applications written to POSIX can be portable across a VERY large range of systems (more than just UN*X, although that's clearly "home"). It isn't intended as a standard for (just) "UN*X". Specifically, the missing "number of blocks" field represents a common, but NOT universal concept. Since the number of *portable* applications that reasonably would use such a field is small, it was not included, in the interest of not excluding implementations - That doesn't mean that it can't be provided by an implementation. - That doesn't mean that it can't be mandated by a profile (that is a spec like the X/Open Portability Guide, the SVID, or the OSF AES.) - That doesn't mean that the application is not portable among a smaller range of systems that provide such a field. (In this case, the applications that would portably use the field are probably tied exactly to the systems that have the concept at all, and thus (probably) provide the field. 3) POSIX isn't yet complete, or even close. - There are a lot of complaints about POSIX being "incomplete" in that it doesn't specify functionality in a certain area. - There are also a lot of complaints about the books being too thick. (How else would you get completeness and precision.) - There are also a lot of complaints about the process going too rapidly. - There are also a lot of complaints about it not being "loose" enough to accommodate everyone. (E.g. the current rules on the semantics of fork() preclude a fully conformant MS-DOS implementation.) - There are complaints (such as this one) that it isn't "tight" enough or that it's incomplete and not reaching completeness rapidly enough. Choose your devil. Additionally, there will always be new needs. There will also be concepts that are not broadly accepted at one time, that due to changing market conditions, will be acceptable later. Thus the standard will evolve to reflect needs even after the current "catch up" period is completed. Maybe the missing field will someday in the future become so common in implementations that it can be standardized. 4) Lastly, please don't whine about it: come help us make it right. If you think it's wrong, don't take potshots at it about how it's broken or "braindamaged". Join us and help us make it right. Even if you don't always get your way (and believe me, noone ever does, because one man's "braindamaged" is another's "perfect" and another's "it will break my customers applications") you will understand why the decisions were made, and what the benefits are; you may also be the person who tips the balance on something you care about. The next meeting is at the Swissotel, Chicago, April 15-19. You can register at the door, or preregister. You can participate by mail. (Look for a posting in comp.std.unix in the near future that will cover that as well as other things.) I'd like to say participation is free, but it simply can't be. Meeting rooms and copying cost money, and for something the size of POSIX we just have run totally out of Sugardaddies to pay for such things. Donn Terry Chair, IEEE 1003.1 My comments reflect only my own opinions, not those of either the IEEE or my employer. (IEEE yells at me to make that clear.)
terryl@sail.LABS.TEK.COM (03/09/91)
In article <1991Mar07.073936.12552@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In article <3419@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >>It's truly a pity that System V has more marketing clout; BSD is just SO >>much more usable. > >In what way? On kithrup, I have job control, command-line editing (I use >ksh), networking (still useful even though kithrup is the only machine it >can connect to 8-)), and a few other nifty-keen things. I ... know of some >other useful things coming out, but I can't comment on them. Well, I, too use a SYSV machine that has all of the neat (and nice!! (-:) Berkeley extensions, i.e. job control, FFS (Fast File System for all you non- TLAers out there!!! (-:), and some other goodies; I don't like it as much as a REAL BSD(TM of someone out there, I'm sure!!! (-:). Why??? I can still backspace over my prompt...... __________________________________________________________ Terry Laskodi "There's a permanent crease of in your right and wrong." Tektronix Sly and the Family Stone, "Stand!" __________________________________________________________ PS: For the humor-impaired amongst you out there, sprinkle even more (-: than I already have, i.e. (in my best Foghorn Leghorn voice): "It's a joke, son!!!!" And yes, although it does have job control, it doesn't have the NEWER tty driver that handles things like my complain graciously......
guy@auspex.auspex.com (Guy Harris) (03/09/91)
>Of course, one could argue that a standard should not try to define too >much...but I think POSIX purposely decided to look more like System V and >ignore all the interesting bits that made BSD better. Why, I'm not sure. One can think so only if one ignores the presence of, say, "mkdir()", "rmdir()", and "rename()", or a BSD-flavored signal mechanism in POSIX. (Does anybody know of a drug that can be used to cure religious attachment either to System V or to BSD? A version that can be administered via the lungs would be idea, because it could be introduced into the air conditioning system at the next USENIX.... Further development on the drug, to cure religious attachments to *any* operating system, would also be nice.)
sef@kithrup.COM (Sean Eric Fagan) (03/09/91)
In article <6499@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >One can think so only if one ignores the presence of, say, "mkdir()", >"rmdir()", and "rename()", or a BSD-flavored signal mechanism in POSIX. I hereby place, into the public domain, the following POSIX-compliant rename(): #include <unistd.h> #include <errno.h> int rename(from, to) char *from, *to; { if (access (from, 0) == -1) return -1; errno = EBUSY; return -1; } -- 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.
src@scuzzy.in-berlin.de (Heiko Blume) (03/10/91)
terryl@sail.LABS.TEK.COM writes: >I don't like it as much as >a REAL BSD(TM of someone out there, I'm sure!!! (-:). > Why??? I can still backspace over my prompt...... try tcsh then. (of course i'd kill for a real BSD too :-) -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
guy@auspex.auspex.com (Guy Harris) (03/10/91)
>As for symbolic links, POSIX had no real support for them last I >checked. I suspect Sean Fagan is thinking of an upcoming update to 1003.1, which *will* specify, among other things, symlinks.
gwyn@smoke.brl.mil (Doug Gwyn) (03/11/91)
In article <3419@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >I think that POSIX is an attempt at an implementation of a bare-bones OS. >There are too many things there which are simply done wrong. POSIX is not an implementation of anything; it's a set of standards that allow people to specify certain minimal levels of functionality when they purchase computer systems. In particular, IEEE Std 1003.1 conformance guarantees that programs written to not step beyond the bounds of what is specified by that standard will operate correctly in a wide variety of different (POSIX-compliant) environments. I'm not aware of very many real problems with IEEE Std 1003.1. >Of course, one could argue that a standard should not try to define too >much...but I think POSIX purposely decided to look more like System V and >ignore all the interesting bits that made BSD better. Why, I'm not sure. As a member of the original P1003 working group, I can tell you that the 1984 /usr/group Standard, minus the portion adopted by X3J11, formed the starting point for Std 1003.1. It is fairly obvious why an organization of commmercial UNIX users and vendors (/usr/group) would have followed UNIX System V more closely than 4BSD. In the course of preparing Std 1003.1, P1003 was careful to consider BSD features as well as System V features, among other possibilities. The final standard was not an exact match to ANY existing system, but it did specify a fairly high level of functionality that could be met with relative ease by commercial vendors. >It's truly a pity that System V has more marketing clout; BSD is just SO >much more usable. In my opinion, having used both systems extensively, a raw UNIX System V Release 2 environment and a raw 4.3BSD environment are both not up to my personal standards of usability, although in different ways. Combined environments are better, and enhanced shell features and nice bitmapped terminal features help too. At the programming interface level, which is what Std 1003.1 was addressing, the System V terminal handler interface (which in a modified form was adopted by 1003.1) is much better than 4.3BSD's, while other 4BSD features are being adopted in extensions to 1003.1.
tchrist@convex.COM (Tom Christiansen) (03/11/91)
From the keyboard of gwyn@smoke.brl.mil (Doug Gwyn):
:In article <3419@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes:
:>I think that POSIX is an attempt at an implementation of a bare-bones OS.
:>There are too many things there which are simply done wrong.
:POSIX is not an implementation of anything; it's a set of standards
:that allow people to specify certain minimal levels of functionality
:when they purchase computer systems.
[deleted text]
:At the programming interface level, which is what Std 1003.1 was
:addressing, the System V terminal handler interface (which in a
:modified form was adopted by 1003.1) is much better than 4.3BSD's,
:while other 4BSD features are being adopted in extensions to 1003.1.
Doesn't the idea of extensions and optional features diminish the
usefullness of certain minimal levels of functionality? Wouldn't it have
been better if these had been place in the dot-1 core?
--tomdonn@hpfcdc.HP.COM (Donn Terry) (03/12/91)
>Sean Fagan writes about an implementation of rename(): 1) There are similar degenerate cases in any standard you care to name; the phases "quality of implementation" and "suitability to purpose" come to mind. 2) Where were you for the last Wierdnix contest?? Donn Terry Speaking only for myself. -------------------------------- >In article <6499@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>One can think so only if one ignores the presence of, say, "mkdir()", >>"rmdir()", and "rename()", or a BSD-flavored signal mechanism in POSIX. >I hereby place, into the public domain, the following POSIX-compliant >rename(): >#include <unistd.h> >#include <errno.h> >int >rename(from, to) >char *from, *to; { > if (access (from, 0) == -1) > return -1; > errno = EBUSY; > return -1; >} >-- >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. >----------
gwyn@smoke.brl.mil (Doug Gwyn) (03/12/91)
In article <1991Mar11.014633.22876@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >Doesn't the idea of extensions and optional features diminish the >usefullness of certain minimal levels of functionality? Wouldn't it have >been better if these had been place in the dot-1 core? Better for some purposes, worse for others. My point is, let's participate in ongoing standardization, but also let's refrain from bashing the past decisions. The people involved thought they had made the best tradeoffs, and second-guessing them now is rather a waste of time.
donn@hpfcdc.HP.COM (Donn Terry) (03/13/91)
>Doesn't the idea of extensions and optional features diminish the >usefullness of certain minimal levels of functionality? Wouldn't it have >been better if these had been place in the dot-1 core? 1) There are lots of features that might have been put in POSIX; we simply havn't gotten there yet. Yes, not having certain capabilities limits the range of applications that might be written as "conforming applications". 2) Options are a tool for compromise: - sometimes options are used to get agreement on the standard at all. (Job control: if it wasn't optional it probably wouldn't have been there at all. However, it's now become commonplace in implementations that used to resist it.) - sometimes options are used because not all users want it. Should high levels of security interfaces be required of all implementations? How about checkpoint/restart? Realtime? These can be expensive (and sometimes irritating "features") that not all users want. Thus programs that need these features can use them, but limit their operation to those systems that provide them. (In a standard fashion.) 3) What is minimally required is very much subject to debate. POSIX.1 is pretty minimal, yet job control, Berkeley-style signals, and several other "minimal" functions met with very strong opposition. The flames around waitpid(), although vital to fix blatant bugs in popen()/pclose() and system(), were spectacular. One persons's minimal is another's creeping featurisim. Again, you can't please all of the people all of the time, and in the case of POSIX there's also simply the amount of time it takes to get the work done. One other observation on this discussion, associated with another response: the POSIX signals are not quite like any existing implementation; there are other features that have that same characteristic. There's a real reason for that, but one which is not obvious: As is often observed, UN*X isn't really very well documented; the code is the true documentation. This is true of all implementations I know of. However, when you try to write it down in a form that can be implemented correctly from the documentation (a requirement for a valid standard), you find that you can't: - Because you don't really know what it does. (Experiments and codereading were a big part of the POSIX work.) - Because you simply can't warp the English (or French) language far enough to explain what's really going on. - Because it's inconsistent between historical implementations that tried to guess what was intended, and guessed differently (not necessarily wrongly, just differently). (And you don't want to break existing implementations (which usually means breaking existing applications), which would be a real disservice to the intended users.) - Because when you write down what it really does, you realize that it "just happened" and the behavior is nonsensical (either due to flawed initial implementation or historical evolution). (Much historical code is that way; every time I've tried to *thoroughly* document something that wasn't coded to a formal design or which had been frequently hacked, I've found things that "just happened" that don't make sense once written down.) (This is the distinction between "works most of the time" and "works right, period".) Signals historically had all these problems. (E.g. the fact that the same signal arriving "too rapidly" could cause an unexpected abort; try requiring that in a standard!) Berkeley signals didn't have as many of the problems, but couldn't be reconciled to coexist with System V signals (without breaking applications). Additionally, the interface wasn't extendable beyond 32 signals (bits) (or whatever a long was). The new interface is extendable and can be reconciled with both "old" signal systems in a reasonable way to avoid breaking applications. We didn't make the changes to signals (or anything else) "just because we felt like it". There was a lot of debate (some of it rather "noisy") on the topic to try and hammer out something that was livable for the long term, and which did not break (very many) existing applications. Donn Terry Speaking only for myself, again.
woods@eci386.uucp (Greg A. Woods) (03/15/91)
In article <9090@sail.LABS.TEK.COM> terryl@sail.LABS.TEK.COM writes: > In article <1991Mar07.073936.12552@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > >In article <3419@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: > >>It's truly a pity that System V has more marketing clout; BSD is just SO > >>much more usable. Hmmm.... That just depends on who you are, and what you can do! > >In what way? On kithrup, I have job control, command-line editing (I use > >ksh), networking (still useful even though kithrup is the only machine it > >can connect to 8-)), and a few other nifty-keen things. I ... know of some > >other useful things coming out, but I can't comment on them. > Why??? I can still backspace over my prompt...... >[....] > And yes, although it does have job control, it doesn't have the > NEWER tty driver that handles things like my complaint graciously...... (It has an even newer tty driver called termio(7) which is better than tty(4) or newtty(4)! :-) Ah, maybe you missed the importance of one thing Sean said above. He uses ksh, which doesn't need newtty(4). [Yes, I know this means you only have those features while at the shell prompt.] Besides, I think there are some versions of termio(7) with newtty-like line disciplines. If not, you could write one instead of complaining (or goad someone else into writing one! :-). On V.4 it's only a STREAMS module! Besides, user-interface extras like newtty are not really appropriate for a specification like POSIX. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
guy@auspex.auspex.com (Guy Harris) (03/19/91)
>Besides, I think there are some versions of termio(7) with newtty-like >line disciplines. If not, you could write one instead of complaining >(or goad someone else into writing one! :-). On V.4 it's only a >STREAMS module! And it has the user-interface features of BSD, as S5R4's "ldterm" is derived from SunOS 4.x's "ldterm". >Besides, user-interface extras like newtty are not really appropriate >for a specification like POSIX. Yup. In fact, the user-interface extras that are *in* POSIX, such as ECHOE, ECHOK, and possibly ECHONL, are probably inappropriate for POSIX as well....
greywolf@unisoft.UUCP (The Grey Wolf) (03/26/91)
/* <5980071@hpfcdc.HP.COM> by donn@hpfcdc.HP.COM (Donn Terry) * 3) What is minimally required is very much subject to debate. POSIX.1 is * pretty minimal, yet job control, Berkeley-style signals, and several * other "minimal" functions met with very strong opposition. The flames * around waitpid(), although vital to fix blatant bugs in popen()/pclose() * and system(), were spectacular. That job control and self-resetting signal handling met with opposition is only a sign that the dinosaurs (people-type dinosaurs, not machines) are fighting a losing battle and they want everyone else to feel the wounds they are taking. An interactive operating system without the capacity for job control is as next to useless as one can get without removing, say, the "minimal" tty editing functions (erase, kill, intr, quit, [d]susp (at least in this case)...). Oh, and everyone worries about security, too. What a joke! You want security? Hire two military goons (best descriptive term, no offense meant) to guard the fireproof, lead-shielded door to a fireproof, lead-shielded room, and cut off all serial and network ports to the computer save the peripherals in the same room (and the console). Not only will your system be secure after that, but because you don't have the overhead of dealing with the interrupts caused by serial port or ethernet traffic, you'll find the response time on the console real snappy! :-) :-) :-) * * One persons's minimal is another's creeping featurisim. One person's minimal is another's nightmare. * Donn Terry * Speaking only for myself, again.
gwyn@smoke.brl.mil (Doug Gwyn) (03/29/91)
In article <3446@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >That job control and self-resetting signal handling met with opposition is >only a sign that the dinosaurs (people-type dinosaurs, not machines) are >fighting a losing battle and they want everyone else to feel the wounds they >are taking. An interactive operating system without the capacity for >job control is as next to useless as one can get without removing, say, >the "minimal" tty editing functions (erase, kill, intr, quit, [d]susp >(at least in this case)...). People who were not involved should not presume to know what the arguments were. In fact, the 4.2BSD job control hack was a horrible abomination with a large number of technical problems. POSIX.1 had to reengineer it just to address most of the security and other substantive issues. It is still widely felt that the job control hack is one of the most inelegant parts of any UNIX variant that has it. Certainly there have been much better designs for facilities that render the BSD-style hack unnecessary.
bzs@world.std.com (Barry Shein) (03/30/91)
From: gwyn@smoke.brl.mil (Doug Gwyn) >People who were not involved should not presume to know what the >arguments were. In fact, the 4.2BSD job control hack was a horrible >abomination with a large number of technical problems. POSIX.1 had >to reengineer it just to address most of the security and other >substantive issues. It is still widely felt that the job control >hack is one of the most inelegant parts of any UNIX variant that >has it. Certainly there have been much better designs for facilities >that render the BSD-style hack unnecessary. Unfortunately, this is where standards activities go right off the deep-end. The very thought that "POSIX.1" had to "reengineer" job control gives me the willies (whatever they are, but I'm sure I have them now!) Has anyone implemented this design-by-committee? Does it actually work (other than in theory)? Is it performant? Is it useful? I sincerely believe that when some facility is found lacking the standards committees should either (although these aren't mutually exclusive, necessarily): 1. Table that part of the standard, publish their reasons, and hope something comes along. 2. Standardize the industry practice with some sort of caveat that they have serious reservations and will likely change this in the future (being as many vendors already have the "industry practice" implemented this is hardly a major headache). 3. Solicit proposals for implementations, already in use (or wait for them to become in use), which meet the committees' criteria, and then standardize the result of that experience. But the idea of "anyone with budget to show up at a standards committee meeting" reengineering anything is a horrid thought. Sort of like arithmetic by majority vote. Is there anything more to getting a vote on or a say in these reengineerings than merely being able to show up at the door and (perhaps) fog a mirror??? I was at a 1201 meeting and almost everyone was eager to redesign X from scratch. Unfortunately, near as I could tell less than a third of the people in the room had ever even written a program in their life, let alone had any credentials to do such work. (I realize Doug Gwyn is probably quite capable of doing most any of these things, so what? I was in the room at 1201, so was Scheifler, that was TWO votes out of 40, and at least half the room was filled with drooling human-factors zomboids with masters degrees in advanced rat-mazing techniques and SCIENTIFIC PROOF that red was a better color for buttons than blue or some such nonsense and wanted all of X reengineered based on their occult knowledge, and had never heard of either of us. I never went back, feh! arithmetic by majority vote.) This sort of behavior is what dooms all these standards efforts. They should be outlawed, the whole thing is sincerely idiotic. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
cgy@cs.brown.edu (Curtis Yarvin) (03/30/91)
In article <3446@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >...as next to useless as one can get without removing, say, >the "minimal" tty editing functions (erase, kill, intr, quit, How many applications that you use keep the terminal in cooked mode? If the answer is "too many," I recommend the "fep" program, which gives any "cooked" app history and other editing features. Needless to say, it uses with raw-mode (and a pty). Unlesss you are a godlike typist, your life will become much easier. Cooked mode is obsolete. It was originally an efficiency hack to reduce I/O processing; this has long been a marginal optimisation. Any text interface written today should use the GNU "readline" libraries, or an equivalent. curtis "I tried living in the real world Instead of a shell But I was bored before I even began." - The Smiths
sef@kithrup.COM (Sean Eric Fagan) (03/30/91)
In article <BZS.91Mar29171508@world.std.com> bzs@world.std.com (Barry Shein) writes: >Has anyone implemented this design-by-committee? Does it actually work >(other than in theory)? Is it performant? Is it useful? Yes. SCO. kithrup (this machine) in an example of how it works. It has its problems, I will admit, but it works. -- 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.
rob@wilbur.coyote.trw.com (Robert Heiss) (03/30/91)
In article <70319@brunix.UUCP> cgy@cs.brown.edu (Curtis Yarvin) writes: [cooked mode bashing...] > >Cooked mode is obsolete. It was originally an efficiency hack to reduce I/O >processing; this has long been a marginal optimisation. Any text interface >written today should use the GNU "readline" libraries, or an equivalent. > Call me a Luddite, but I think readline is overkill. We have lots of small programs with command line interfaces, and there was an experiment with readline, and here's my opinion of it: 1. Readline is a disk space pig. The readline library is larger than the entire Bourne shell executable. Thus every little program which uses it will be around 100K bytes or more. 2. Readline is a memory pig. Since readline messes with heap memory allocation, there is a potential memory leak at every prompt. 3. Readline is a CPU pig. Piping a batch file into a command line is slower when the program uses readline. 4a. Readline is a documentation pig. Until the standard cooked mode and the supported shells have compatible features, the documentation for each program must cover the readline stuff too. And thoroughly too; you can't just mention EMACS or some crufty experimental shell and expect that Joe User has the commands memorized. 4b. Readline violates the principle of least surprise. Since Joe User doesn't have documentation or help for the readline features, he is baffled when mistyping a magic character exposes some complex and stateful behavior. 5. Typing readline commands accidentally at a non-readline prompt can cause major unwanted effects on other computer systems. On the other hand, backspace seems to be universally portable. (except to EMACS :-) 6. Readline is CS friendly, not user friendly. It makes the computer more interesting without providing meaningful productivity improvement. The delete-character feature of cooked mode is necessary and sufficient for command line editing. Kill-line is the next most useful feature. They're good enough to get the job done. ----- Robert Heiss rob@wilbur.coyote.trw.com
jb107@prism.gatech.EDU (Jim Burns) (03/30/91)
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? -- BURNS,JIM (returned student & GT Research Institute staff member) Georgia Institute of Technology, Georgia Tech Station 30178, Atlanta Georgia, 30332 | Internet: jb107@prism.gatech.edu uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jb107
gwyn@smoke.brl.mil (Doug Gwyn) (03/30/91)
In article <BZS.91Mar29171508@world.std.com> bzs@world.std.com (Barry Shein) writes: >But the idea of "anyone with budget to show up at a standards >committee meeting" reengineering anything is a horrid thought. Oh, I quite agree. Unfortunately, there was a lot of pressure from those like the one to whom I was originally responding, who felt that POSIX.1 simply HAD to specify BSD-like "job control" facilities. I wanted them omitted. The compromise was to try to fix the major problems and make the feature "optional". (Of course, NIST went ahead and mandated it in the FIPS. They always seem to think they know better than the technical committees who develop the standards.) I have heard criticism of the POSIX style of job control also, as broken although in a different way from BSD's. I will say that I have NEVER gotten my (actually, Ron Natalie's) job-control Bourne shell to work 100% under ANY flavor of job control, due to occasional races and other problems involving interactions between the terminal handler, kernel security features, and process groups. Then there is the vhangup() kludge, which was deemed by P1003 as inappropriate in a System V-based implementation. >This sort of behavior is what dooms all these standards efforts. They >should be outlawed, the whole thing is sincerely idiotic. There is indeed a serious problem with most of the UNIX-related software standardization work these days. There seem to be a large number of people who think that simply HAVING a standard is somehow a desirable goal, quite apart from whether or not it is a good standard. Unfortunately such people are quite willing to go through all the effort to promulgate their point of view and get standards actually adopted, and once they start work there is no stopping them.
sef@kithrup.COM (Sean Eric Fagan) (03/31/91)
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.
oz@yunexus.yorku.ca (Ozan Yigit) (04/01/91)
In article <15621@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >Certainly there have been much better designs for facilities >that render the BSD-style hack unnecessary. Which ones? Why were they better? [I do have Ritchie's thoughtful discussion on this already, would be neat to have yours too. ;-|] oz --- Anything is a little trickier when | Internet: oz@nexus.yorku.ca it's orbiting Venus. -- Amanda Walker | Uucp: utai/utzoo!yunexus!oz
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/01/91)
In article <1991Mar30.202637.8629@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > 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). Idiotic. Absolutely idiotic. UNIX has always worked on the principle that if you have permission to open a file, you can open it, and use the descriptor forever. *Normal file access permissions handle security*. Now POSIX has to introduce more than thirty changes (by my count) to the tty and signal-handling systems, all in the name of tty security. Not a single change was justified by experience from more than one vendor, and most of them were entirely new. Few of them make sense. Why did POSIX make these changes? Because they did not understand that *normal file access permissions handle security*. They thought (correctly) that the tty subsystem was insecure, and they thought (incorrectly) that a bunch of ad-hoc changes would fix the problem. Convex UNIX 9.0 is a (supposedly) POSIX-compliant system. Not only does the OS follow every stupid POSIX restriction, but it introduces several new ad-hoc restrictions on tty access. You would think that this would eliminate all tty security holes. Not so. On every available BSD-based system---including Convex UNIX 9.0 and mainstream systems like SunOS and Ultrix---I can gain invisible write and TIOCSTI access to any tty, with a short program and no privileges. I sent such a sample program to Tom Christiansen not long ago, and it was both funny and sad to watch the ensuing panic. I keep telling people that the tty subsystem is insecure. I keep telling them how to fix it, with a simple set of basic changes, not the huge pile of inconsistent, senseless, ad-hoc rules that has found its way into every POSIX system. Berkeley still doesn't listen. Keith Bostic, are you listening? I'm sure someone will forward this to you if not. If I can write a program to break tty security under a standard BSD 4.4 setup, I will distribute that program as widely as I can. I guarantee you that this will happen if you do not make some fundamental changes to the BSD 4.3 + POSIX tty system. You think this is a threat? Then take it as a threat. It's only sympathy for the huge BSD 4.3 installed base that has kept me from distributing such a program already. BSD 4.4 will not have that installed base, and I see absolutely no ethical or legal reason to remain quiet about such a pervasive set of security holes. On the flip side, if you have enough interest in security to want to eliminate the holes, I'm perfectly willing to tell you how. You don't have to break POSIX compatibility (though it would be easier that way), and none of the necessary changes are very difficult (though again it would make a simpler system if you did put in more effort), and I'm not even going to pretend that you need a pty manager (though that would greatly reduce the number of lines you'd have to change in applications). Hell, you can get most of this information from Steve Bellovin. But if you're too lazy to ask, I'm not going to tolerate tty insecurity any more. > I found this in emacs, > incidently. The POSIX folks don't even understand backwards compatibility. Shameful. ---Dan
sef@kithrup.COM (Sean Eric Fagan) (04/01/91)
In article <4269:Apr105:57:0091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: (Dan and I have had this argument before, and we'll have it again 8-).) >In article <1991Mar30.202637.8629@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >> 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). >Idiotic. Absolutely idiotic. UNIX has always worked on the principle >that if you have permission to open a file, you can open it, and use the >descriptor forever. *Normal file access permissions handle security*. So. I start a pty session, that means I can send any arbitrary signal to any process on the slave side? Gee, that doesn't sound right. The issue in question was that BSD pty's allow the master side of the pty to query (using TIOCGPGRP) to get the process group of the slave side. This is the same ioctl as one would normally use on a normal tty, to find out the process group of one's own tty. emacs then uses the resulting value to send a signal to it. This, incidently, does not work when the slave side of the pty is running under a different uid. Now: SCO's OS's never had this ioctl until 3.2, which added (broken until 3.2v2) job control. Therefore, they never had any backwards compatability. The reason sco doesn't do what berkeley does is because POSIX says that any process attempting to read (or do an tcgetpgrp, which essentially does the TIOCGPGRP ioctl in sco's implementation) shall have certain things happen under certain circumstances. For example, if the process in question is in a different pgrp than the tty in question, it shall get a signal (or something like that; I don't have 1003.1 with me right now, so I can't quote verbatim). In SCO's implementations of pty's, all ioctls, except for one or two, get passed to the tty driver, which is where the checks mentioned in passing above happen. Therefore, it doesn't allow that to happen. When I found this, it was too late to change it for 3.2v2, and, besides, I wasn't sure what should happen. So I enquired of the folks at CSRG, and a query was sent to the POSIX folks. CSRG responded with, essentially, "Ooops, we hadn't noticed that, you're right, here's what we're going to do," so I did what they said they did (although I want to confer with them again about it). Meanwhile, the POSIX query (as well as a query to rms) indicated that, since pty's are an extension, any behaviour is allowed by posix, so we could have "made" the old behaviour work. However, since I didn't like it, for a reason listed above, I didn't do that. (Besides, I liked the TIOCSIG ioctl 8-)). >Why did POSIX make these changes? Because they did not understand that >*normal file access permissions handle security*. Not entirely. Part of it is for *sanity*. Most of the changes I think you're referring to deal with what should happen when different pgrp's try to access a tty. Guess what: they all can have the same uid. I am not going to make any definitive statement without 1003.1 handy, though. Please tell me, for example, why a different process group should be able to change the pgrp associated with *my* tty? Since that pgrp may even be in a different session, on a different tty, but still have my uid, why should it be able to lock me out? >Not so. On every available BSD-based system---including Convex UNIX 9.0 >and mainstream systems like SunOS and Ultrix---I can gain invisible >write and TIOCSTI access to any tty, with a short program and no >privileges. Several people have commented that TIOCSTI is an abomination that should be forgotten. Neither SCO nor POSIX have it. >On the flip side, if you have enough interest in security to want to >eliminate the holes, I'm perfectly willing to tell you how. I think I asked you about your objections to POSIX, about a year ago, and you just complained that it broke things. Nothing about security. >> I found this in emacs, >> incidently. >The POSIX folks don't even understand backwards compatibility. Shameful. Gee, they broke some SysV'isms, yet I bet you don't complain about that. -- 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.
mbrown@testsys.austin.ibm.com (Mark Brown) (04/01/91)
(Barry Shein) writes: |From: gwyn@smoke.brl.mil (Doug Gwyn) |>People who were not involved should not presume to know what the |>arguments were. In fact, the 4.2BSD job control hack was a horrible |>abomination with a large number of technical problems. POSIX.1 had |>to reengineer it just to address most of the security and other |>substantive issues. It is still widely felt that the job control |>hack is one of the most inelegant parts of any UNIX variant that |>has it. Certainly there have been much better designs for facilities |>that render the BSD-style hack unnecessary. | | Has anyone implemented this design-by-committee? Does it actually work | (other than in theory)? Is it performant? Is it useful? Yes. Yes. Yes. Yes. In fact, I've seen it running on a few different OSs, ranging from AIX to BSD-variants to MACH-variants. Blind fear doesn't look good on you..... Mark Brown MAIL: mbrown@testsys.austin.ibm.com OR uunet!testsys.austin.ibm.com!mbrown Which came first: The Chicken or the Legba? DISCLAIMER: Any personal opinions stated here are just that.
chip@tct.com (Chip Salzenberg) (04/01/91)
According to sef@kithrup.COM (Sean Eric Fagan): >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. Seconded. SCO UNIX 3.2v2 has POSIX job control that works. Got to give 'em credit when it's due. -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
mbrown@testsys.austin.ibm.com (Mark Brown) (04/01/91)
sef@kithrup.COM (Sean Eric Fagan) writes: > jb107@prism.gatech.EDU (Jim Burns) writes: > 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? >[numerous commands that close up on signals] > 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-)). Essentially, the problem is that to *fully* implement POSIX-style job control, you have to convert commands such as vi and csh that look for BSD-specific things. csh, in particular, will develop a pipe race condition if a detailed conversion isn't done to POSIX line-discipline setup. Yeah, this is a gripe, but after the conversion is done, it works without the hitches Sean describes.... Mark Brown IBM PSP Austin, TX. (512) 823-3741 VNET: MBROWN@AUSVMQ MAIL: mbrown@testsys.austin.ibm.com OR uunet!testsys.austin.ibm.com!mbrown Which came first: The Chicken or the Legba? DISCLAIMER: Any personal opinions stated here are just that.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/02/91)
In article <1991Apr01.083503.27317@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > In article <4269:Apr105:57:0091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Idiotic. Absolutely idiotic. UNIX has always worked on the principle > >that if you have permission to open a file, you can open it, and use the > >descriptor forever. *Normal file access permissions handle security*. > So. I start a pty session, that means I can send any arbitrary signal to > any process on the slave side? Gee, that doesn't sound right. Of course you can send a signal to a process on the slave side, provided you're the owner of that process. TIOCSIG is a separate abomination. > Please tell me, for example, why a different process group should be able to > change the pgrp associated with *my* tty? If a tty is in the filesystem, and it is writable to you, and accessing the tty for writing lets you change its pgrp, then you can change its pgrp. Why? Because that's normal UNIX security. The problem with the current BSD + POSIX setup is that you can go beyond the file permissions. > >Not so. On every available BSD-based system---including Convex UNIX 9.0 > >and mainstream systems like SunOS and Ultrix---I can gain invisible > >write and TIOCSTI access to any tty, with a short program and no > >privileges. > Several people have commented that TIOCSTI is an abomination that should be > forgotten. Neither SCO nor POSIX have it. Under SunOS and Ultrix, at least, I can also get *read* access, though this involves some race conditions. But write access is already a huge security violation. > >On the flip side, if you have enough interest in security to want to > >eliminate the holes, I'm perfectly willing to tell you how. > I think I asked you about your objections to POSIX, about a year ago, and > you just complained that it broke things. Nothing about security. You only asked for examples. Yes, my biggest complaint about POSIX is that in many cases it preserves *neither* the System V *nor* the BSD semantics. Instead it invents new, more complex semantics, with rationales as convincing as ``tty security'' (which they have failed to achieve). Did you know that the POSIX definition of ``background process'' does not agree with the BSD definition? So where does it come from? Why is it useful? There's *nothing* in the rationale to justify this change. > >> I found this in emacs, > >> incidently. > >The POSIX folks don't even understand backwards compatibility. Shameful. > Gee, they broke some SysV'isms, yet I bet you don't complain about that. I'm not familiar enough with System V to see where POSIX made silent changes. I can see some spots where POSIX changed from the System V behavior to the BSD behavior, and usually they tried to preserve the original semantics as a special case. If you show me some System V applications that break as badly as emacs, screen, atty, et al. under BSD + POSIX, I'll be glad to complain about them. However, tty security is a much more important problem right now for the real world, POSIX aside. I'll bet that your system hasn't closed any of the System V tty security holes that Steve Bellovin pointed out years ago. The latest I heard from Berkeley indicates that BSD 4.4 ttys will be just as insecure as BSD 4.3 ttys. WHY SHOULD EVERY SINGLE AVAILABLE BSD SYSTEM LET ANYONE BECOME ROOT? ---Dan
cgy@cs.brown.edu (Curtis Yarvin) (04/02/91)
In article <564@bria> uunet!bria!mike writes: >In article <70319@brunix.UUCP> cgy@cs.brown.edu (Curtis Yarvin) writes: >>Cooked mode is obsolete. It was originally an efficiency hack to reduce I/O >>processing; this has long been a marginal optimisation. Any text interface >>written today should use the GNU "readline" libraries, or an equivalent. > >They're good enough to get the job done. >I have found that people who tend to think like Curtis (no offense intended >to him), tend to be those people who are used to the PC-type of UNIX >environment (consoles that sit on the bus, and a relatively small number >of users on the system) as opposed to the good 'ol 9600 bps terminals on >a system with 50-100 users. Certainly. On a 100-user mainframe, canonical mode is not a marginal optimisation. My point was that the good 'ol 9600 bps terminals & large time-sharing systems are likely to pass away soon, except in heavy-duty transaction processing environments. Networking technology (in my opinion) has become simple, reliable, and effective enough that a mainframe is rarely the most cost-effective option when purchasing a new system. >You have 50 busy people on serial terminals typing away, that non-canonical >input combined with a memory pig is not going to be looked upon favorably, >regardless of how many features it has. Typing away on what? sh? ed? If they're using a shell with editable history (as most prefer), or they're editing a file, they're in raw mode. If you have such a mongo mainframe around, and you have kmem privileges, it might be interesting to run some tests and see exactly how much time is spent in canonical mode. curtis "I tried living in the real world Instead of a shell But I was bored before I even began." - The Smiths
karish@mindcraft.com (Chuck Karish) (04/02/91)
In article <15645@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >(Of course, NIST went ahead and mandated [ that the POSIX.1 job control >option be supported ] in the FIPS. They always seem to think they >know better than the technical committees who develop the standards.) Customers are such an annoyance. They're always demanding things that the implementors don't think they should have. Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
rbj@uunet.UU.NET (Root Boy Jim) (04/02/91)
In article <15645@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >(Of course, NIST went ahead and mandated [ that the POSIX.1 job control >option be supported ] in the FIPS. They always seem to think they >know better than the technical committees who develop the standards.) Believe me, they don't. BTW, I assume that what Berkeley and Sun have done (setsid and friends) is what you're talking about. I would imagine that this fixes the security problems, but still uses the tty process group to multiplex terminal input, which probably drives Doug up the wall. Barry, why didn't you ask Kirk about this when y'all were here last week? -- [rbj@uunet 1] stty sane unknown mode: sane
rbj@uunet.UU.NET (Root Boy Jim) (04/02/91)
In <CNH5730.91Mar30113957@maraba.tamu.edu> cnh5730@maraba.tamu.edu writes: ?In <BZS.91Mar29171508@world.std.com> bzs@world.std.com (Barry Shein) writes: ? Has anyone implemented this design-by-committee? Does it actually work ? (other than in theory)? Is it performant? Is it useful? ? ?Is performant a real word? Is it necessary? Isn't the English ?vocabulary large enough already? Perhaps performant means "conformant" + "performs"? Barry has been reading the Dissociated Press. -- [rbj@uunet 1] stty sane unknown mode: sane
goudreau@larrybud.rtp.dg.com (Bob Goudreau) (04/02/91)
In article <127225@uunet.UU.NET>, rbj@uunet.UU.NET (Root Boy Jim) writes: > ? Has anyone implemented this design-by-committee? Does it actually work > ? (other than in theory)? Is it performant? Is it useful? > ? > ?Is performant a real word? Is it necessary? Isn't the English > ?vocabulary large enough already? > > Perhaps performant means "conformant" + "performs"? Yeah, then how come I can't find "conformant" in my dictionary either? I suspect that it's one of those bastardized combinations of two other words, like "irregardless" (coined by someone who confused & combined "irrespective" and "regardless"). In "conformant"'s case, the collision appears to be between "conforming" and "compliant". ---------------------------------------------------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation goudreau@dg-rtp.dg.com 62 Alexander Drive ...!mcnc!rti!xyzzy!goudreau Research Triangle Park, NC 27709, USA
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (04/02/91)
cgy@cs.brown.edu (Curtis Yarvin) writes: | Cooked mode is obsolete. It was originally an efficiency hack to | reduce I/O processing; this has long been a marginal optimisation. Any | text interface written today should use the GNU "readline" libraries, | or an equivalent. This is argueable; some of us think we have better solutions to this than giving every application the intelligence of GNU Emacs; usually this involves running all our programs under some sort of "front end" that we like better. Available front ends range from things like GNU Emacs, through pty-based general line editing and history tools like atty and fep, to special windowing terminal programs such as Sun's cmdtool or 'sux' (an X11 emulation of the Blit/DMD 'mux' text interface). My personal favorite of these is 'sux'; with it I get scrollbars (and thus command and output recall) and full cut and paste (and resend) editing of my entire session. I've found that it's amazingly convenient once you get used to it; it has easily replaced my usage of tcsh and fep and similar tools. [I know not everyone has windowing terminals these days, but we are talking about the future here, not current realities.] -- V9: the kernel where you can do fgrep <something> */*.[ch] and not get "Arguments too long". cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
lewine@cheshirecat.webo.dg.com (Donald Lewine) (04/02/91)
In article <15645@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes: |> (Of course, NIST went |> ahead and mandated it in the FIPS. They always seem to think they |> know better than the technical committees who develop the standards.) |> NIST was specifying what the customer wanted. Options in POSIX allow customers to vote with their dollars. I would not buy a system without job control for my personal use. i don't want to buy one with my tax dollars either. POSIX technical committees can create all of the options that they want (look at .4). Buyers are going to want to put them in. In the end, POSIX will create profiles in the same way that Detroit created "luxury option groups". Buyers are not willing to deal with all of the options. ------------------------------------------------------------------- Donald A. Lewine (508) 870-9008 Voice Data General Corporation (508) 366-0750 FAX 4400 Computer Drive. MS D112A Westboro, MA 01580 U.S.A. uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
cgy@cs.brown.edu (Curtis Yarvin) (04/03/91)
In article <1991Apr2.032733.26365@jarvis.csri.toronto.edu> cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) writes: >cgy@cs.brown.edu (Curtis Yarvin) writes: >| Cooked mode is obsolete. It was originally an efficiency hack to >| reduce I/O processing; this has long been a marginal optimisation. Any >| text interface written today should use the GNU "readline" libraries, >| or an equivalent. > This is argueable; some of us think we have better solutions to this >than giving every application the intelligence of GNU Emacs; usually >this involves running all our programs under some sort of "front end" >that we like better. [ cites various front ends ] Certainly; but bear in mind that all these front ends use the "pty" driver, which is a bletcherous hack*, kludged in to get around the problems that cooked mode causes. I should be able to fake normal keyboard input with a simple pipe. When you use, e.g. "fep", you are using "readline" anyway. You're just sending the result through an extra device driver to fake cooked mode. More efficient? I think not. The ideal solution would be a reasonably-standard, dynamically linkable input library, so you could link to whatever interface you preferred. >[I know not everyone has windowing terminals these days, but we are > talking about the future here, not current realities.] Exactly. *: I am NOT criticizing the implementation or the design of the pty driver. In fact, I consider pty a necessity. I am criticizing the obsolete design which makes it a necessity. curtis "I tried living in the real world Instead of a shell But I was bored before I even began." - The Smiths
bagwill@swe.ncsl.nist.gov (Bob Bagwill) (04/03/91)
I was... <flame suit on> the author of the first version of the termios section of the NIST POSIX Conformance Test Suite and of the first version of the test assertions for that chapter, but I wasn't a member of the POSIX.1 or .3 work groups. <weeping violin playing softly in the background> Writing test assertions and tests for POSIX or UNIX based merely on POSIX.1 or SVID is no fun. I cheated and read source code to try to understand what was going on. You remember the story about the four blind men and the elephant. Given the descriptions from the blind men, how would you write a field guide to identifying elephants? And given the field guide, could you build an elephant from scratch? (Sorry for the characterization of the POSIX work groups as blind men :-) Firing up another metaphor here... IMHODI (In my humble opinion and deep ignorance) UNIX is like the Bible (I'll leave it to someone more knowlegable to write a humorous version of the history of UNIX recast in biblical terms). It was written by many people in many languages over many years. Each author claimed to be divinely inspired. :-) Each publisher of subsequent revisions had to guess what the original authors REALLY meant. Each contributing editor felt free to rewrite, restate, translate, discard, etc. any pieces that didn't fit, and add their own extensions, explanations, etc. POSIX is just the most recent edition. It's no surprise that it's not backward compatible. It's no surprise that everyone wants to add stuff.
gwyn@smoke.brl.mil (Doug Gwyn) (04/03/91)
In article <670533623.5140@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >In article <15645@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >>(Of course, NIST went ahead and mandated [ that the POSIX.1 job control >>option be supported ] in the FIPS. They always seem to think they >>know better than the technical committees who develop the standards.) >Customers are such an annoyance. They're always demanding things >that the implementors don't think they should have. Nonsense -- NIST/NBS claimed to be representing Federal UNIX users, but what they actually did was prepare a poll on the optional features which a SMALL number of users got to vote on at a workshop, then mandated the items that received majority votes, no matter how ill- advised it might be to mandate the specific features for SOME procurements, and even without concern over whether the particular combination of features was an intelligent packaging. This is the common selection of true "democracy" over "representative republic" that is uncritically accepted by many Americans these days as desirable. (The Founding Fathers were aware of the problems with true democracies, which is why they tried not to establish one.) In fact, as a Federal UNIX user of some note I much prefer to NOT have POSIX-style job control forced upon me, as it makes it less likely that I will be able to acquire better solutions that might not be compatible with such features.
jik@athena.mit.edu (Jonathan I. Kamens) (04/03/91)
In article <70568@brunix.UUCP>, cgy@cs.brown.edu (Curtis Yarvin) writes: |> The ideal solution would be a reasonably-standard, dynamically linkable |> input library, so you could link to whatever interface you preferred. Yet another example of Unix doing now what Multics did long ago, and people thinking it's a wonderful new innovation. "Those that do not learn from history are doomed to repeat it." :-) -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
guy@auspex.auspex.com (Guy Harris) (04/04/91)
>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. Oh, I certainly agree. TIOCGPGRP on the master side of a pty should report what process group the pty master is in, that process group being the one to which a SIGIO is sent whenever I/O is possible on the master side. TIOCSPGRP on the master side should set that process group. That process group is, of course, completely independent of the process group the *slave* is in. TIOCSIG, or something like it, is the right answer if the process on the master side has to send a signal to the slave side. If one is worried about security, one can restrict it to sending SIGINT, SIGQUIT, and SIGTSTP. >(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. Absolutely! Sending tty signals to the slave side of a pty by doing a TIOCGPGRP and a "kill()" is the wrong answer.
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (04/04/91)
cgy@cs.brown.edu (Curtis Yarvin) writes: | My point was that the good 'ol 9600 bps terminals & large time-sharing | systems are likely to pass away soon, except in heavy-duty transaction | processing environments. Networking technology (in my opinion) has | become simple, reliable, and effective enough that a mainframe is | rarely the most cost-effective option when purchasing a new system. You might be surprised by what trends are starting to manifest. 9600 baud terminals do indeed seem to be on the way out, but their preferred replacement (at least around here) is often a bigger, heftier server and a bunch of X terminals. Workstations tend to be saved for 'autonomous' people, for those with special needs (such as playing around with new software before installing it on the production server), or people who need high-bandwidth graphics. -- V9: the kernel where you can do fgrep <something> */*.[ch] and not get "Arguments too long". cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (04/04/91)
cgy@cs.brown.edu (Curtis Yarvin) writes: | Certainly; but bear in mind that all these front ends use the "pty" | driver, which is a bletcherous hack*, kludged in to get around the | problems that cooked mode causes. My favorite frontend, the terminal-emulator based one, needs a pty anyways to talk to my shell; it's common these days for the method people use to access their machines to need at least one pty. I also think that many of the bletcherousnesses of ptys would probably go away if they were reimplemented using something general like stream connections. Whether or not ptys and streams are a bletcherous hack depends on your views on the desirability of having different sorts of tty modes around, and how much you want to start adding such semantics to pipes. Personally, I think they're quite usefull, and can be expressed and used in elegant ways. -- V9: the kernel where you can do fgrep <something> */*.[ch] and not get "Arguments too long". cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
martin@adpplz.UUCP (Martin Golding) (04/06/91)
In <1991Apr3.123809.29779@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <70568@brunix.UUCP>, cgy@cs.brown.edu (Curtis Yarvin) writes: >|> The ideal solution would be a reasonably-standard, dynamically linkable >|> input library, so you could link to whatever interface you preferred. > Yet another example of Unix doing now what Multics did long ago, and people >thinking it's a wonderful new innovation. > "Those that do not learn from history are doomed to repeat it." :-) Those who learn from history get big bucks for repeating it. Martin Golding | sync, sync, sync, sank ... sunk: Dod #0236 | He who steals my code steals trash. A poor old decrepit Pick programmer. Sympathize at: {mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp
bvs@BitBlocks.COM (Bakul Shah) (04/07/91)
In article <681@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes: | In <1991Apr3.123809.29779@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: | | >In article <70568@brunix.UUCP>, cgy@cs.brown.edu (Curtis Yarvin) writes: | >|> The ideal solution would be a reasonably-standard, dynamically linkable | >|> input library, so you could link to whatever interface you preferred. | | > Yet another example of Unix doing now what Multics did long ago, and people | >thinking it's a wonderful new innovation. | | > "Those that do not learn from history are doomed to repeat it." :-) | | Those who learn from history get big bucks for repeating it. No, no, no! The usenet version is quite different: ``Those who think they have learned from history _insist_ on repeating it to the net.'' And a corollary: ``Those who know such people are doomed to listen them repeat it.'' :-)
greywolf@unisoft.UUCP (The Grey Wolf) (04/10/91)
/* <70319@brunix.UUCP> by cgy@cs.brown.edu (Curtis Yarvin)
* In article <3446@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes:
* >...as next to useless as one can get without removing, say,
* >the "minimal" tty editing functions (erase, kill, intr, quit,
*
* How many applications that you use keep the terminal in cooked mode? If the
Probably too many for your tastes. I happen to enjoy cooked mode usually
a lot more than raw mode (because the terminal doesn't grab my input line
immediately).
* answer is "too many," I recommend the "fep" program, which gives any
* "cooked" app history and other editing features. Needless to say, it uses
* with raw-mode (and a pty). Unlesss you are a godlike typist, your life will
* become much easier.
Well, actually, I can type pretty fast (though not entirely accurately :-)).
I find that I can optimally use things like word-kill, line-kill or delete
depending upon how far I've gone on the line.
What's gained by putting a raw-mode interface between you and the terminal?
It's an extra process and a tty/pty pair. Over a network that becomes
redundant. Besides that, for every layer you add, response does go down.
Minimally, okay, but most times (*MOST*) I can notice the little bit of
added sluggishness when I type on that extra layer.
#ifdef CSH_BASHER
I use csh, and I like it. I can get more accomplished with the C shell
than I was ever able to do using the korn shell. The code is ugly, okay.
The syntax can be ugly, okay. Vi mode in ksh is a pain. Emacs mode is
worse. Both are more sluggish. I like a nice instantaneous feedback from
my shell's command line. There are other reasons why I don't use ksh or
BRL sh or bash or whatever, but they're not relevant to the issue at hand.
Csh rebuttals are kindly redirected >& /dev/null.
#endif
*
* Cooked mode is obsolete.
Depends upon the level you're looking at. If you're looking at it through
serial lines, then yes, cooked mode is obsolete (usually due to the lack
of serial lines on the computer). If you're looking at it through the net-
work, then no, I must disagree. I prefer working in cooked mode to working
in raw mode for the reason I stated above.
You can extoll your raw-mode-simulating-cooked-mode interfaces all you want,
but I will insist that that extra layer of overhead simply gets in my way.
* It was originally an efficiency hack to reduce I/O
* processing; this has long been a marginal optimisation. Any text interface
* written today should use the GNU "readline" libraries, or an equivalent.
*
But why put an extra layer there...? You're not saving anything by doing
that, either, really. And such a thing would be a lose on a shell. The
one advantage I can see is that one could do convenient things like defining
both Backspace *AND* delete to be "delete", or have both
control-Z and control-P be "suspend" or whatever.
*
* curtis
*cgy@cs.brown.edu (Curtis Yarvin) (04/10/91)
In article <3478@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >21@smoke.brl.mil> <70319@brunix.UUCP> >Reply-To: greywolf@unisoft.UUCP (The Grey Wolf) >Organization: Foo Bar and Grill >Lines: 65 > >/* <70319@brunix.UUCP> by cgy@cs.brown.edu (Curtis Yarvin) > * In article <3446@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: > * >...as next to useless as one can get without removing, say, > * >the "minimal" tty editing functions (erase, kill, intr, quit, > * > * How many applications that you use keep the terminal in cooked mode? If the > >What's gained by putting a raw-mode interface between you and the terminal? >It's an extra process and a tty/pty pair. Over a network that becomes >redundant. Besides that, for every layer you add, response does go down. >Minimally, okay, but most times (*MOST*) I can notice the little bit of >added sluggishness when I type on that extra layer. Exactly! But this is my point. If cooked mode did not exist, you would not have to use a pty. Pty is there to fake cooked mode in the first place. And your input might even be faster, because the application could use something a little cleaner than the kernel's clists to process it. Or it could use something big and heavy, like readline, and get more functionality. Either way, it would be up to the application, which is the way it should be. Personally, I like emacs-style history editing. You prefer simple erase-kill processing. Isn't it better to get the choice out of the kernel, and let each application decide what it wants? There is only one reason I have seen for keeping cooked mode. If you have an external I/O processor which knows how to cook, it can save some work. But how many people actually have such a beast? curtis
geoff@world.std.com (Geoff Collyer) (04/11/91)
Curtis Yarvin: >Isn't it better to get the choice out of the kernel, and let each >application decide what it wants? No, it isn't. The last thing I want is each application having a different idea of what I have to type to erase input (for example). `Gee, now I'm in emacs, so I have to type control-A control-K to erase my line.' Ugh. One of the great wins of Unix is that it lets the *user* make such choices, not J. Random Losing Application (unless it switches to cbreak mode, which is becoming distressingly common). This is one reason that cooked mode is a win (fewer context switches being the other obvious one) and that shell globbing is a win: they are done centrally, by one piece of code, so they work uniformly and all applications and users benefit. (Yeah, we know about "restore *".) -- Geoff Collyer world.std.com!geoff, uunet.uu.net!geoff
ed@mtxinu.COM (Ed Gould) (04/11/91)
>Personally, I like emacs-style history editing. You prefer simple >erase-kill processing. Isn't it better to get the choice out of the kernel, >and let each application decide what it wants? No, it's not better to get it out of the kernel, unless you propose linking the *same* interface into *every* application. I want consistency among the tools I use. I most certainly do not want to remember which applications have fancy input editing built in and which don't. -- Ed Gould No longer formally affiliated with, ed@mtxinu.COM and certainly not speaking for, mt Xinu. "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
jik@athena.mit.edu (Jonathan I. Kamens) (04/11/91)
In article <1991Apr10.192226.24909@world.std.com>, geoff@world.std.com (Geoff Collyer) writes: |> Curtis Yarvin: |> >Isn't it better to get the choice out of the kernel, and let each |> >application decide what it wants? |> |> No, it isn't. The last thing I want is each application having a |> different idea of what I have to type to erase input (for example). The point, Geoff, which I tried to make in my earlier reference to Multics (although perhaps the reference was missed by many people who are not familiar with how Multics does what I was talking about), is that it is possible to *both* remove the input processing from the Kernel, *and* allow a uniform input interface for all clients. The way Multics did things was by allowing users to plug their own input interface library in between the terminal and whatever programs they were running. That library could include line-editing, history editing, and anything else the user chose to write into it. The programs being run didn't control how the input editing happening, the user did when putting his chosen editing interface into place. (I've probably got the terminology all wrong above, since I never programmed under Multics and don't remember all the words they used instead of what we use under Unix, but you get the idea. :-) Now, I've never programmed with streams, but I was under the impression that it's possible to use them to do something like this. Can't the user write a streams driver that does his line-editing, etc. for him, and set the tty to use that driver by default, so that applications that don't muck with the line discipline will automatically have whatever interface the user installs? In my opinion, this is the right direction to go. And, as I said in my previous message, Multics was doing it long ago. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
chris@imsdx3.UUCP (Chris Ott) (04/12/91)
Oh well, someday I hope to post an article that's useful to someone, but for now, I guess I'm just going to have to be satisfied with complaining about the general state of things. In article <1991Mar30.202637.8629@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) claims: > (Yes, sco does listen and look at the bug reports!) Hmm... I find this hard to believe, considering the amount of stuff that was left out of SCO UNIX. For example: 1) Symbolic links. C'mon guys, how hard can this be to implement? 2) Reasonably long filenames. Yes, I know 14 characters is "standard" System V, but gimme a break. I don't think you need to go all out and allow 255 characters like BSD, but you've added extenstions anyway. At least allow 30 or 40 characters. 3) SCO UNIX does not have a real C compiler. Aside from some pretty basic C constructs that it doesn't accept, it doesn't even produce COFF output files. It produces Xenix output files, and runs a program (cvtomf?) to convert them to COFF format. This wouldn't be so bad if it wasn't for the fact that I often get the message "Too many modules" or something. Arrgh. In fact, after looking around the system, we've decided that a large number of the utilities have actually been copied straight from Xenix, since most of them are Xenix object files. 4) Also, don't try to defend yourself by saying that you're trying to be "standard" System V. The thing that gets me the most is that SCO UNIX has all these extensions, when the basic stuff isn't all there. That should have been taken care of first. The extensions shoudn't have been added until afterwards. As an example, I was unable to compile GCC on SCO UNIX; I had to compile it on a Prime EXL (which compiled it using the same configuration without so much as a warning message, incidently) and copy the binary over to the SCO machine. There are plenty of other problems; these are just the ones I could think of off the top of my head. I can't believe that I'm the only person who wants these capabilities. I'm probably not even in the minority, so, if SCO really does listen to their customers, why aren't they in there? -- =============================================================================== Chris Ott | Infatuation is blind, not love. A person Information Management Systems | in love can see the other's faults, but ...!uunet!bria!imsdx3!chris | loves them anyway.
martin@mwtech.UUCP (Martin Weitzel) (04/12/91)
In article <1991Apr10.192226.24909@world.std.com> geoff@world.std.com (Geoff Collyer) writes: >The last thing I want is each application having a >different idea of what I have to type to erase input (for example). >`Gee, now I'm in emacs, so I have to type control-A control-K to erase my >line.' Ugh. One of the great wins of Unix is that it lets the *user* >make such choices, not J. Random Losing Application (unless it switches >to cbreak mode, which is becoming distressingly common). The idea sounds right, but the implementation is too poor for todays hardware. One of the biggest problems in this area is that the level to which a "user" can configure the kernel (more exactly the TTY-driver) is at the level of 20 years old hard-copy terminals, dumb "glass ttys" at best. Look, there are still numerous possibilities to specify delays, tab expansion and things I hardly ever need with todays hardware, but tell me how I can make the "cursor right" key (which happens to send three characters, I know, that's something botched too but quite another topic) be my "erase" key? Further, how can I edit the beginning of the line without deleting from the end? The reason that so many applications switch to cbreak mode is just that too *few* is done in the device driver or line discipline. (I'm sure if slightly "intelligent" CRT-displays were commonly used at the time Thompson and Ritchie started with UNIX, the situation were better ...) >reason that cooked mode is a win (fewer context switches being the other >obvious one) The cost for context switches is not extremly high on modern hardware, so that one should not worry too much about this. Well, I don't have exact numbers - does anyone else? Let's assume 5 msec and someone who types 5 characters per second - this will cost 2.5 % CPU cycles. OK, if there are 10 to twenty users this would become more considerable, but often the user will sit there watching the output (and think or drink coffee or whatever) so that the *average* typing rate is probably much below my guess. (Further, the fact that so many programs today *do* switch to cbreak mode can be taken as indication that context switches aren't so much of a problem for modern hardware :-). Do you notice a degradation in performance when many users are working with vi?) >and that shell globbing is a win: they are done centrally, >by one piece of code, so they work uniformly and all applications and >users benefit. (Yeah, we know about "restore *".) I see you know :-) ... and also processing of command-line options for programs (or at least some preprocessing) should have been done centrally from the beginning on ... -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (04/14/91)
In article <3478@unisoft.UUCP>, greywolf@unisoft.UUCP (The Grey Wolf) writes: > /* <70319@brunix.UUCP> by cgy@cs.brown.edu (Curtis Yarvin) [bashing back and forth about cooked mode] > * Any text interface written today should use the GNU "readline" > * libraries, or an equivalent. > But why put an extra layer there...? You're not saving anything by > doing that, either, really. And such a thing would be a lose on a > shell. The one advantage I can see is that one could do convenient > things like defining both Backspace *AND* delete to be "delete", or > have both control-Z and control-P be "suspend" or whatever. Since I use a shell that does run in cbreak.... The usefulness of such an interface promises to be as much a religious issue as editor wars or keyboard quality arguments. So to throw my two cents into the fray.... I find it to be a major *win* in the shell. Not just because I can define both \10 and \177 as "delete", though that capability is nice to have. Much more important is the ability to edit the command-line at points other than the current end. I occasionally have to use systems without such shells, so I have a constant basis for comparison. A rough estimate is that using the shell I do, instead of a standard sh or csh, saves me perhaps ten minutes per day. And the cost is minimal; another rough estimate places the cost at well under 1 cpu-second per day, and most of those cycles would otherwise be burnt in the idle loop. No, it's unquestionably worth it. For me. (If you want to claim that shells running in cooked mode should be available, you won't get any argument out of me.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mike@bria.UUCP (Michael Stefanik) (04/15/91)
In an article, chris@imsdx3.UUCP (Chris Ott) writes: >In article <1991Mar30.202637.8629@kithrup.COM>, sef@kithrup.COM >(Sean Eric Fagan) claims: >> (Yes, sco does listen and look at the bug reports!) > >Hmm... I find this hard to believe, considering the amount of stuff that >was left out of SCO UNIX. For example: [ list of things that SCO has munged up, like no sym links and a funky compiler ] I agree completely. I have a fundamental problem with some of the technical and marketing decisions that SCO has made with XENIX and UNIX. As Chris has said, symbolic links are rather fundamental, as well as "long" filenames. Why weren't they included? It seems to me that SCO basically regurgitated their XENIX stuff (including alot of the binaries), slapped a new box on it, and charged a *whole lot more* money for the product. It is dissapointing enough that they strip everything down to the bare metal and charge and arm and a leg to have the system "enhanced" to a usuable level ... with C2 included in the stinking mess. Simply bletcherous. Followups to comp.unix.sysv386 -- Michael Stefanik, MGI Inc, Los Angeles | Opinions stated are never realistic Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- If MS-DOS didn't exist, who would UNIX programmers have to make fun of?
rbj@uunet.UU.NET (Root Boy Jim) (04/16/91)
In article <1991Apr14.094953.12840@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >> But why put an extra layer there...? You're not saving anything by >> doing that, either, really. And such a thing would be a lose on a >> shell. The one advantage I can see is that one could do convenient >> things like defining both Backspace *AND* delete to be "delete", or >> have both control-Z and control-P be "suspend" or whatever. BTW, don't forget that cbreak and cooked mode are another layer on top of raw mode, altho it is done in the kernel. >Since I use a shell that does run in cbreak.... Me too. Mostly tcsh, but I'm comfortable with ksh too. >The usefulness of such an interface promises to be as much a religious >issue as editor wars or keyboard quality arguments. So to throw my two >cents into the fray.... Yeah, but maybe we can agree this time :-) >I find it to be a major *win* in the shell. Not just because I can >define both \10 and \177 as "delete", though that capability is nice. YES! Let many keys map to one function. One useful one is "break", (or "newline") which sends the accumulated string up to the user. A text editor might set all control characters to this and all printables to self-insert. >Much more important is the ability to edit the command-line at >points other than the current end. I occasionally have to use systems >without such shells, so I have a constant basis for comparison. And ain't it horrible? It makes my head hurt. >A rough estimate is that using the shell I do, instead of a standard sh >or csh, saves me perhaps ten minutes per day. Which I promptly waste again reading/posting news :-) >And the cost is minimal; >another rough estimate places the cost at well under 1 cpu-second per >day, and most of those cycles would otherwise be burnt in the idle >loop. No, it's unquestionably worth it. For me. (If you want to >claim that shells running in cooked mode should be available, you won't >get any argument out of me.) My point is that I want my food well-done. I think the real challenge is to put readline and termcap into the kernel. By now, everyone's terminal should be ANSI and require no padding, so simple line editing should be reasonable to do. Give names to the functions, and allocate a keymap (or a pointer to the parent's, with copy on write semantics) to each user. Likewise, allocate a termcap structure. There would be no context switching to allow user code to process each keystroke as is done with cbreak mode. If the kernel did enuf editing, the shell could run in cooked mode and still be usable. Raw mode as always for programs that want to do everything. -- [rbj@uunet 1] stty sane unknown mode: sane
meissner@osf.org (Michael Meissner) (04/16/91)
In article <111@imsdx3.UUCP> chris@imsdx3.UUCP (Chris Ott) writes: | 1) Symbolic links. C'mon guys, how hard can this be to implement? I was working with a UNIX vendor that did this, and it was painful to get all of the commands modified to support symlinks correctly. | 2) Reasonably long filenames. Yes, I know 14 characters is "standard" | System V, but gimme a break. I don't think you need to go all out | and allow 255 characters like BSD, but you've added extenstions | anyway. At least allow 30 or 40 characters. Again, you have to go through the commands. Not all of the original System V (III, 7) commands used appropriate include files. Many 'knew' about 14. You can't even grep for 14, you also have to look for 13 and 15. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
guy@auspex.auspex.com (Guy Harris) (04/16/91)
>No, it's not better to get it out of the kernel, unless you propose >linking the *same* interface into *every* application. Well, I suspect that's what some *are* proposing - either linking it into every application (although perhaps doing so dynamically, and transparently, so that anybody who does a cooked-mode "read()" from a tty gets the data passed through that code), or sticking it in front of the tty as a pty-based front end. >I want consistency among the tools I use. I most certainly do not want >to remember which applications have fancy input editing built in >and which don't. I'm not sure *I* wouldn't want it. Most of the cooked-mode typing I do is to a shell, and I found it not to be a real problem to have a whizzy editor only in "ksh". Maybe it wouldn't be a problem having "ksh"s input editing code in wired-down kernel code, and maybe it wouldn't be wired down, but....
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/16/91)
As quoted from <1991Apr11.140508.9012@athena.mit.edu> by jik@athena.mit.edu (Jonathan I. Kamens): +--------------- | Now, I've never programmed with streams, but I was under the impression that | it's possible to use them to do something like this. Can't the user write a | streams driver that does his line-editing, etc. for him, and set the tty to | use that driver by default, so that applications that don't muck with the line | discipline will automatically have whatever interface the user installs? In | my opinion, this is the right direction to go. And, as I said in my previous | message, Multics was doing it long ago. +--------------- der Mouse and I had this discussion two years ago. I'm still waiting to get my hands on a Unix with a Streams tty driver so I can show him some code... but SunOS and SVR4 have the capability already. It should be possible to come up with something that has a compatible program interface (whether "compatible" means termio, termios, or sgtty) yet has a user interface which provides line editing, history, etc. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
gwyn@smoke.brl.mil (Doug Gwyn) (04/16/91)
In article <1991Apr11.140508.9012@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > Now, I've never programmed with streams, but I was under the impression that >it's possible to use them to do something like this. Can't the user write a >streams driver that does his line-editing, etc. for him, and set the tty to >use that driver by default, so that applications that don't muck with the line >discipline will automatically have whatever interface the user installs? As I understand it (not programming Streams either), the only streams modules that you can get the kernel to insert are ones that have been built into the kernel, i.e. not user-mode code. That seems to me to be a major deficiency in the current streams design, although it is clear why the restriction exists. >In my opinion, this is the right direction to go. I would agree, more or less. Streams certainly open up possibilities.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (04/16/91)
As quoted from <111@imsdx3.UUCP> by chris@imsdx3.UUCP (Chris Ott): +--------------- | 4) Also, don't try to defend yourself by saying that you're trying to | be "standard" System V. The thing that gets me the most is that | SCO UNIX has all these extensions, when the basic stuff isn't all | there. That should have been taken care of first. The extensions | shoudn't have been added until afterwards. As an example, I was +--------------- Is there an echo in here? (1/2 :-) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
cgy@cs.brown.edu (Curtis Yarvin) (04/16/91)
In article <129131@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: > >I think the real challenge is to put readline and termcap into the kernel. Kernel? You mean the "watermelon," right? As someone has already pointed out, the cost of context switching to handle character I/O is negligible on most new systems. Why bloat the kernel any more? Why not put it in a shlib and let the apps use it? >If the kernel did enuf editing, the shell could run in cooked mode and still >be usable. This is a wild goose chase, in my opinion. Applications will continually want more kernel editing, and cooked mode will become less and less of a useful feature and more and more of an ugly backward-compatibility hack. Eventually, you're right back where you started, with everyone using raw/cbreak mode; except that the kernel is now twice as big. This is how Unix got the way it is. Curtis
rbj@uunet.UU.NET (Root Boy Jim) (04/17/91)
In article <MEISSNER.91Apr15215423@curley.osf.org> meissner@osf.org (Michael Meissner) writes: >In article <111@imsdx3.UUCP> chris@imsdx3.UUCP (Chris Ott) writes: > >| 1) Symbolic links. C'mon guys, how hard can this be to implement? > >I was working with a UNIX vendor that did this, and it was painful to >get all of the commands modified to support symlinks correctly. I can see that it might cause *some* pain, but it should be worth it. I hope their definition of "correct" was correct. Basicly, any command that deals with the file system as a tree structure (dump, tar, rm, etc) should treat symlinks specially (not follow them), while most programs should treat them as hard links. One good way to identify these programs would be to grep for 'stat('. -- [rbj@uunet 1] stty sane unknown mode: sane
rbj@uunet.UU.NET (Root Boy Jim) (04/17/91)
In article <72242@brunix.UUCP> cgy@cs.brown.edu (Curtis Yarvin) writes: ?In article <129131@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: ?> ?>I think the real challenge is to put readline and termcap into the kernel. ? ?Kernel? You mean the "watermelon," right? I like that. Actually, I mean a subset of the two. Note that one doesn't have to be ruthless about optimizing each micro termcap motion; that is clearly wasted effort. ?As someone has already pointed out, the cost of context switching to handle ?character I/O is negligible on most new systems. Why bloat the kernel any ?more? Why not put it in a shlib and let the apps use it? I recall much talk about adding an extra layer. ?>If the kernel did enuf editing, the shell could run in cooked mode and still ?>be usable. ? ?This is a wild goose chase, in my opinion. Applications will continually ?want more kernel editing, and cooked mode will become less and less of a ?useful feature and more and more of an ugly backward-compatibility hack. ?Eventually, you're right back where you started, with everyone using ?raw/cbreak mode; except that the kernel is now twice as big. This is how ?Unix got the way it is. I don't think so. Both tcsh and ksh use more or less the same commands, the same as the one-stroke emacs commands (vi mode users, take off, eh? Maybe you'll learn emacs if we spoon feed it to you in the terminal driver). There are only so many ways to do things. The path is clear. Besides, I don't see that a clean, efficient, reasonably complete implementation couldn't be written in less space than the current terminal driver. -- [rbj@uunet 1] stty sane unknown mode: sane
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (04/20/91)
rbj@uunet.UU.NET (Root Boy Jim) writes: | I think the real challenge is to put readline and termcap into the kernel. | By now, everyone's terminal should be ANSI and require no padding, so | simple line editing should be reasonable to do. "Should" is, I think the right word here. "Is" is definetly the wrong one; a significant chunk of local terminals are not ANSI, and many terminals can't manage to always keep up at 9600 baud. Of the terminals and terminal types I use regularly, only one is ANSI-ish -- and that's the xterm. Indeed, my favorite "terminal type" has neither terminal emulation nor need of readline et al in applications that run under it, since it's an X11 clone of the Blit/DMD5620/AT&T630 mux text window that Doug Gwyn has already described; it happily lets me edit text all over the place before sending the resulting lines to Unix. Not to mention our hardcopy console terminals. -- "This will be dynamically handled, possibly correctly, in 4.1." - Dan Davison on streams configuration in SunOS 4.0 cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
rbj@uunet.UU.NET (Root Boy Jim) (04/23/91)
In article <1991Apr19.170447.8051@jarvis.csri.toronto.edu> cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) writes: ?rbj@uunet.UU.NET (Root Boy Jim) writes: ?| By now, everyone's terminal should be ANSI and require no padding, so ?| simple line editing should be reasonable to do. ? ? "Should" is, I think the right word here. "Is" is definetly the wrong ?one; a significant chunk of local terminals are not ANSI, and many ?terminals can't manage to always keep up at 9600 baud. In that case you don't get to use all that nifty editing, or perhaps only a subset of it. At NBS, the excess property people didn't even bother hauling the many Datamedia 1521 terminals to whoever auctions them off. They'd simply SMASH the screens, and throw them away. Televideo 950's were still kept, but will end up there as soon as they've reached the end of their devaluation schedule. Cheap Wyse's are now what, $200 or so? Do they even make terminals without ANSI compatible stuff anymore? And by padding, I meant the per-command stuff, such as screen clear, not continuous blasting. Besides, we're talking 80 character line retyping here. If all else fails, run the damn terminal slower. I don't care to support ancient or bizarre hardware. As to the Blit's you mention, well they need a slew of software anyway. And hardcopy terminals don't really count. Besides, I also mentioned putting a small subset of termcap into the kernel. The tty driver will do the best it can with the information it has. But we have to make some rules. No half duplex terminals (this restriction already exists). No uppercase only. No Hazeltine braindamage. No padding supported. No tab expansion (I might change my mind on this one). There is already a lot of code supporting all those features I just mentioned. I'd like to swap it for something useful. -- [rbj@uunet 1] stty sane unknown mode: sane
hollings@poona.cs.wisc.edu (Jeff Hollingsworth) (04/25/91)
In article <130073@uunet.UU.NET>, rbj@uunet.UU.NET (Root Boy Jim) writes: |> Besides, I also mentioned putting a small subset of termcap |> into the kernel. The tty driver will do the best it can |> with the information it has. Why put more stuff in the Kernel? We should be looking at how to take things out of the Kernel and get it back down to a smaller size. ------------------------------------------------------------------------------- Jeff Hollingsworth Work: (608) 262-6617 Internet: hollings@cs.wisc.edu Home: (608) 256-4839 X.400: <pn=Jeff.Hollingsworth;ou=cs;o=uw-madison;prmd=xnren;c=US>
peter@ficc.ferranti.com (peter da silva) (04/26/91)
In article <72242@brunix.UUCP> cgy@cs.brown.edu (Curtis Yarvin) writes: > As someone has already pointed out, the cost of context switching to handle > character I/O is negligible on most new systems. Why bloat the kernel any > more? Why not put it in a shlib and let the apps use it? Same objection as putting the toolkits in shlibs in X. The control flow is all wrong, and you're forcing the application to respond in real-time. Why? Cooked mode is perfectly adequate for 90% of applications, and raw mode is available for the 10% that need more. (and, yes, window management belongs in the bloody server) -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
martin@mwtech.UUCP (Martin Weitzel) (04/26/91)
In article <130073@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >Besides, I also mentioned putting a small subset of termcap >into the kernel. The tty driver will do the best it can >with the information it has. Wild guess: If CRT-terminals with cursor adressing capability were in widespread use in the days Thompson and Ritchie started out with UNIX, we would have lseek(2) (resp. seek(2)) defined for serial lines too. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83