njh@root44.UUCP (06/10/83)
I also agree that `osh' stands for Old Shell. It seemed to be a copy of the Version 6 shell, but because of the lack of /bin/if, /bin/goto (!!), and /etc/glob it wasn't of any use. I can only guess that it shouldn't have gone out but did. Nigel Horne ...!vax135!ukc!root44!njh
guy@rlgvax.UUCP (06/11/83)
Dennis Ritchie informs me (I presume he won't mind if I mention this) that it was, indeed, the V6 shell; it was there because of the Bell port of UNIX to the Interdata. Since the Bourne shell requires so much of the system to work (including, for example, backing up fairly arbitrary instructions after a segmentation violation), he wanted a shell that would work even if the kernel wasn't perfect. Guy Harris RLG Corporation {seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy
mel@houxm.UUCP (06/11/83)
Oh, come on guys! "oanything" as a command name almost always means the "old" version of "anything", just as "nanything" usually means the "new" version. Our computer center systems are full of these at any one time as new things are filtered in. The original question on this a month ago referred to our "osh", the released version of "sh"; as opposed to the running "sh" that has a little added diddle to logoff an idle user (NOT a port hog chaser, but a service to forgetful users who don't like being charged for their idleness). To expand this a gospel over all systems is misleading. We probably need a better, more organized way to handle changes than "o" and "n" prefixes, but human nature prevails. Mel Haas , houxm!mel
dave@utcsrgv.UUCP (Dave Sherman) (06/12/83)
Of course oanything is old and nanything is new. Where do you think nroff came from? (Yes, we did have an "onroff" running here for a while when the new nroff appeared a few years back.) Dave Sherman U of Toronto
Michael.Young%cmu-cs-g@sri-unix.UUCP (06/12/83)
It seems that a nice idea for new software would be to add a directory like /usr/newbin (and /usr/oldbin for old stuff). People could choose to use all new software without having to guess whether they should say "nsh" or "sh" or whatever else the new version might have been named. Michael
satz%sri-tsc@sri-unix.UUCP (06/13/83)
instead of using oanything and nanything, we use anything- and anything+; easier to keep track of things that way.
njh@root44.UUCP (06/15/83)
Rather than anything[+-] or even [on]anything I use [ON]anything cos then they appear at the top of ls's for file purges. (Before the flames appear, who uses stty LCASE anyhow?) Nigel Horne ...!vax135!ukc!root44!njh
rcj@burl.UUCP (06/15/83)
When I get a piece of software, or want to send one out to another site running Unix, I don't ask them if they are running oUnix or Unix or nUnix -- I just ask them if they are running USG or BSD and whether they are running 4.0, 5.0, 2.8 or whatever. Why not do the same for changed software elsewhere: have the newest version of nroff called simply "nroff", and call the old version(s) by some numbering scheme. nroff1, nroff2.4, etc. should be used very infrequently anyway, since everyone should be converting over to the new nroff. -- The MAD Programmer -- 919-228-3814 (Cornet 291) alias: Curtis Jackson ...![ floyd sb1 mhuxv ]!burl!rcj
smh@mit-eddi.UUCP (Steven M. Haflich) (06/16/83)
Curtis Jackson hits the nail right on the thumb with his remarks about naming old versions of programs. His example was that nroff1, nroff2.4, etc. should be used very infrequently anyway, since everyone should be converting over to the new nroff. Really? Which "new nroff?" The original one (the one that replaced roff)? The one that came out around the same time as Unix 6.5-7? The slightly revised version which updates that one? Or is there a new one about which I have heard nothing? I find it tremendously difficult to keep track of versions of the various large system programs on Un*x -- system programs here intended to include compilers, *roff, uucp, etc. -- and similar difficulty establishing where a particular version was written, where its support (such as it is) might be centralized, or where distributions can be obtained. (By the way, I am a Unix wizard of 7 years standing, although I have been reading the net only 8 months or so.) For example, recently I became interested in getting ditroff, if possible, but there is no obvious mechanism to determine its source or availability other than nuisance broadcasts to the net. We have a (monthly?) net posting of the list-of-lists summarizing the currently valid newsgroups. This costs the moderator some time, but is of great service to the community. (If only more new users could could be directed to examine it.) How about something similar for "systems" sources, called "net.versions" or whatever? It could summarize the state of the art for each of the several dozen "systems" and include: - The name of the system. - A brief description of what it does, limited to a line or two. - What it runs under. - The (original) authorship/institution. - Derivation from earlier versions. (e.g. nroff9.2 is an enhanced version of nroff9.1 with bug fixes but no new features). - Availability (and licenseing). Most often this would be a simple entry like "distributed with standard 4.1". Otherwise, the site or sites which are willing to distribute could be named, or if an item is already *widely* distributed, one would know to check adjacent sites first. - If appropriate, a central repository for bug fixes. Look at the current mess with uucp and the news system. Who knows how find all the bug fixes for a given version? I can no longer even keep the versions straight. The reason this will never happen, like so many other things, is that it would take too much work for someone. (Probably a good deal more than the list-of-lists mailing.) I am certainly not volunteering, but maybe some other fool will do so, start a list, and solicit updates and corrections.
gwyn%brl-vld@sri-unix.UUCP (06/17/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> If Bell and Berkeley would make a concerted effort, I am sure that most user utilities could be merged into one common "latest" version. Clearly this would require the latest UNIX license also. I've been porting the entire System III (soon to be V) environment onto 4.1cBSD (soon to be 4.2BSD) for a variety of reasons, a minor one of which is to be able to run some of the "newer" software on 4.1cBSD. When this work is done I will make it available somehow (license verification is a problem) and announce it to the list. P.S. It is hard to emulate some USG features adequately on 4.1cBSD; the worst mismatch is the yucky BSD terminal driver.