Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ucf-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!drutx!mtuxo!mtunh!
mtung!mtunf!ariel!vax135!petsd!peora!ucf-cs!tim
From: t...@ucf-cs.UUCP (Tim Curry)
Newsgroups: net.micro.att
Subject: Several System 5.2 questions
Message-ID: <2067@ucf-cs.UUCP>
Date: Mon, 8-Jul-85 13:31:20 EDT
Article-I.D.: ucf-cs.2067
Posted: Mon Jul 8 13:31:20 1985
Date-Received: Fri, 12-Jul-85 00:40:11 EDT
Organization: Univ. of Central Florida, Orlando
Lines: 102
My configuration: 3B2/300 with System 5.0.5 bought Sept. 1984.
Anyone outside of AT&T with a 3B2 system been upgraded to 5.2?
How many 3B2 systems are there outside AT&T?
I debated with myself whether to break this into several small postings
or one large one. I've opted for one large article. I hope that someone
with all the answers makes it through all the questions. Our software
development will require many different changes depending on what a real
System 5.2 looks like. My account executive is a friendly guy and attempts
to be helpful but just can't get me the kind of answers I need to make
programming decisions and purchase packages. I need to know what I will be
seeing if I can ever get upgraded to 5.2. I am hoping that the majority of
my bad reactions to system 5 vs. BSD are related to the fact that version 0.5
was a quick release to get the machines out the door and version 2 (2.1,2.2)
will be a complete version of UNIX.
1) What is the current release of System 5? I see some postings in this news
group with 5.2.2. Anyone answering subsequent questions please
indicate what version they are refering to.
2) termcap vs. terminfo vs. curses. Our software uses screen manipulations
throughout but system 5.0.5 doesn't have the -lcurses or -ltermcap
I have written my own code with our own termcap-like file but
would much prefer using the system standard. What will 5.2 have?
What is the difference between termcap and terminfo? Will both
stay around or is termcap likely to die. Does 4.3BSD stick with
termcap or move to terminfo? Do the curses routines work with both
termcap and terminfo? Are the curses routines compatable between
4.xBSD and S5? Does terminfo have graphic character information
to allow real boxes to be drawn vs. the box(stdwin,'|','-') type.
Does terminfo distinquish attribute modes by name rather than function.
i.e. "Reverse video" rather than "stand-out mode" which might be "half
intensity" for a different terminal.
3) nroff/troff and "man" command. I have none of these. I believe I heard
that troff might be unbundled to either the documentor's workbench
or writer's workbench but I would think that nroff and man should
be standard on each system. If nroff is available, then are neqn,
table, col etc. also available. If these aren't standard, what
package do I have to buy to get them?
4) is lp (line printer spooler) an optional package or standard? Our software
makes a distinction between a "display" to the terminal and a "report"
to hardcopy. We popen (pipe open) our output for the report to lp
but if this is not standard, then I'm not sure where to send it.
Is there a "printcap" file that describes the command sequences for
printers like in 4.2BSD?
5) virtual memory/record locking - I understand that 5.2 does finally
incorporate virtual memory but is that part of the requirements
for ALL versions of 5.2? e.g. When (or if) the XENIX version that
is 5.2 compatable on the IBM PC is implemented, will it support virtual
memory so that I can freely fork and execl etc. to my hearts content
without worring about a 256k system running out of memory and hence
having to try some overlay techniques or something?!? Likewise, will
all record locking calls be supported identically on all 5.2 compatable
versions?
6) is "make" standard? Does "make" still only come with the C compiler package?
When distributing software (even binarys only) "make" is the usual
way to do it. I suppose that shell scripts can be set up but still ...
7) What is the toolchest? I have been off of the net for 9 months and just
caught the tail end of disscussions about the toolchest when I started
reading USENET again. Where can I get details?
8) Is there an (MS|PC)-DOS C cross compiler available so that I can do my
compile work on the 3B2 and down-load the executable to a PC machine.
I would think that AT&T would have such a beast since the 6300 is
a DOS machine.
9) Does anybody know if I can buy a CSH for the 3B2 from any source? I
understand that the bourne shell under 5.2 has some job control
finally (could somebody tell me how this interface works? Is it
like the csh with ctl-z, fb, bg etc.?) and the shell functions are
probably more powerfull than aliasing in the csh but I desperately
miss the history, push/pop directorys, ~ expansion, and ctl-w word
delete. I use these things EVERY SESSION that I'm on a BSD system.
I simply don't understand why AT&T is hesitant to make the BSD software
available at least as an optional package. I'm 99% sure that they use
a lot of BSD software themselves!! I'd like a lot of programs that
I miss. Since Berkeley is not trying to make a profit from BSD and
the BSD enhancements make a considerably nicer user interface, why
aren't these things available? Furthermore, I know there is a package
that gives System 5.2 support under 4.2BSD but why not the reverse
from AT&T? This would allow the best of both worlds to be available.
10) what is available? Perhaps the last statement was over harsh. Where can
I get a list of what software is available from AT&T and its cost?
The one price I got for the Documentor's Workbench was a Source price.
Are binary prices available for the unbundled protions of UNIX?
11) What does it take to get a software package sanctioned by AT&T for
System 5.2?
Tim Curry
USENET: decvax!ucf-cs!tim
ARPANET: tim.ucf-cs@csnet-relay
--
Tim Curry
USENET: decvax!ucf-cs!tim
ARPANET: tim.ucf-cs@csnet-relay
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cuae2.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!mgnetp!hw3b!
wnuxb!cuae2!heiby
From: he...@cuae2.UUCP (Ron Heiby)
Newsgroups: net.micro.att
Subject: Re: Several System 5.2 questions
Message-ID: <363@cuae2.UUCP>
Date: Thu, 11-Jul-85 13:17:04 EDT
Article-I.D.: cuae2.363
Posted: Thu Jul 11 13:17:04 1985
Date-Received: Sat, 13-Jul-85 09:12:43 EDT
References: <2067@ucf-cs.UUCP>
Reply-To: he...@cuae2.UUCP (Ron Heiby)
Organization: AT&T-IS, /app/eng, Lisle, IL
Lines: 107
Here's the answer to as many of Tim's questions as I could come up with
quickly. Some questions related to BSD features which I am not qualified
to address.
In article <2...@ucf-cs.UUCP> t...@ucf-cs.UUCP (Tim Curry) writes:
>1) What is the current release of System 5?
The currently available version for the 3B2/300 is:
UNIX System V Release 2.0 3B2 Version 2
AT&T has announced a paging release for the 3B2 which
will be available shortly and be (I believe) Release 2.1.
>2) termcap vs. terminfo vs. curses.
"You sure ask a lot of questions." Anyway, SVR2 has libcurses.a and uses
the terminfo database. /etc/termcap is still delivered for software that has
not been recompiled to use terminfo. Termcap is not likely to die completely
as long as there are many systems that do not yet have terminfo. Although,
new development should use terminfo, as it is technically superior. Termcap
is one big file with all the terminal descriptions. Terminfo is a hierarchy
of files, where each file describes one terminal, hence it's more efficient.
Whether termcap or terminfo is used depends on the library code with which
the application was linked. Most of the other questions can be answered
by the terminfo manual.
>3) nroff/troff and "man" command.
The nroff and troff commands (and I think man) are in the Documenter's
Workbench, which is a seperately priced package. Man files for all of
the section 1-n stuff is not supplied, as AT&T feels that a machine of
the class of a 3B2 does not generally have enough free disk space to devote
to that kind of material and the information can be had from the paper copy,
anyway. Documenter's Workbench comes with tbl, eqn, neqn, col, etc.
>4) is lp (line printer spooler) an optional package or standard? Our software
> makes a distinction between a "display" to the terminal and a "report"
> to hardcopy. We popen (pipe open) our output for the report to lp
> but if this is not standard, then I'm not sure where to send it.
> Is there a "printcap" file that describes the command sequences for
> printers like in 4.2BSD?
The LP Spooler package is a seperately priced package. The command to
queue something for printing is named "lp" and is found in /usr/bin. There
is no "printcap" that I know of. Each printer has an interface file (which
is generally a shell script) which handles set-up for each print job.
>5) virtual memory/record locking
"All" versions of UNIX have supported "virtual memory" (with exceptions like
the iAPX-86 architecture, which doesn't do memory management). What is new
is "Demand Paging" rather than "Swapping". System V with demand paging is
currently available for the DEC VAX and AT&T 3B20 systems and has been
announced for the 3B2 and 3B15, although it is not yet available there. It
is extremely unlikely that any implementation of UNIX for AT&T PC 6300
machines (or compatibles) would include demand paging, as there is no hardware
support for it in the iAPX-86 architecture. Those systems would continue to
be swap based. AT&T has committed to supporting the /usr/group standard for
file and record locking across its product line. The currently available
3B2 release supports the "Advisory" locking, which is what most applications
really want. The paging release on the 3B2 supports the "Mandatory" locking,
as well.
>6) is "make" standard?
I assume that you mean "bundled". No, I believe that "make" comes in the
"Extended Software Generation" package.
>7) What is the toolchest?
The AT&T Software Toolchest is a system which provides electronic distribution
of purchased software. Source code is licensed for a fee and delivered via
uucp. The license is not for a single machine, but for every machine in
(at least location, probably organization, can't remember). Binary resale
licenses are available with no per-sale royalty. See your AT&T Account
Executive for more information.
>8) Is there an (MS|PC)-DOS C cross compiler available
I know of now MS-DOS C cross compiler being sold. Sounds good though.
>9) Does anybody know if I can buy a CSH for the 3B2 from any source?
I know of no source for CSH. System V Release 2.0 introduced "Shell Layers",
which many Berkelyites sneer at, but which I find to be quite useful. It
is a facility for having multiple logical terminal sessions multiplexed over
the same connection. See the User Manual for more info [shl(1)]. Regarding
the csh capabilities that you want, you should look into the Korn Shell (ksh)
which is available through the Toolchest. I use nothing else. My guess
about csh not being available from AT&T is that it is rather a botch, changing
quite a few things just for the sake of changing them and is thus quite
incompatible with Bourne. Korn, being 99 and 44/100 % upward compatible with
Bourne does not have this problem. As to any other BSD developments: They
are all known of and looked at by AT&T developers. Some appear in System V,
like "cat -v" and "ls -RadCxmnlogrtyucpFbqisf" and "mailx" (alias Mail). The
thing to remember is that Berkeley is (supposed to be) in the education
business. They do a good job by letting students experiment. AT&T is in the
stable computing environment business. We do a good job by making darn sure
that what we do doesn't break something (like a shell script or worse) and
that we spend our efforts spending resources on the most important/needed
enhancements first.
>10) what is available?
See your AT&T Account Executive. Binary packages are available for the
3B2. Prices are in the price book.
>11) What does it take to get a software package sanctioned by AT&T for
> System 5.2?
By "sanctioned", do you mean in the catalog, AT&T co-labling, or what?
For any of that, you need to talk with the AT&T Independent Software
Vendor program people. Your AT&T Account Executive should be able to
find the right contact.
Have fun.
--
Ron Heiby he...@cuae2.UUCP (via ihnp4)
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!
decwrl!sun!guy
From: g...@sun.uucp (Guy Harris)
Newsgroups: net.micro.att
Subject: Re: Several System 5.2 questions
Message-ID: <2415@sun.uucp>
Date: Fri, 12-Jul-85 04:56:35 EDT
Article-I.D.: sun.2415
Posted: Fri Jul 12 04:56:35 1985
Date-Received: Sat, 13-Jul-85 16:48:42 EDT
References: <2067@ucf-cs.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 158
> 1) What is the current release of System 5?
I believe it depends on what machine you're on. It's S5R2V2 for the VAX.
> 2) termcap vs. terminfo vs. curses. What will 5.2 have?
The VAX 5.2 has the "curses"/"terminfo" package.
> What is the difference between termcap and terminfo?
"terminfo" has a lot more per-terminal capabilities (i.e., control strings,
characteristics, etc.) than "termcap". The database is in a "compiled"
format for faster loading.
> Will both stay around or is termcap likely to die.
There's no technical reason for "termcap" to stick around, other than the
cost of conversion. There is a "termcap"-emulator package in the "curses"
library, so programs written for "termcap" should work (unless they do
something *really* weird), and there is a monster "ex" script that does a
lot of the work of converting "termcap" descriptions to "terminfo"
descriptions. However, "terminfo" requires an S5R2 license, so...
> Does 4.3BSD stick with termcap or move to terminfo?
I don't think they move to "terminfo", unless Pavel Curtis' public-domain
"curses" supports "terminfo" and they picked that up.
> Do the curses routines work with both termcap and terminfo?
The 4.2BSD curses could probably work with "terminfo" using the "termcap"
emulator (but it may do "something really weird", so it may not). The S5R2
"curses" uses a lot of the added capabilities of "terminfo" so it won't work
with "termcap".
> Are the curses routines compatable between 4.xBSD and S5?
Pretty much. I've recompiled a number of "curses"-using programs written
for "old curses" with "new curses" and they work. A number of 4.2BSD
programs already have hooks in them for "new curses" (like "mille" and, I
think, "sysline").
> Does terminfo have graphic character information to allow real boxes
> to be drawn vs. the box(stdwin,'|','-') type.
Not to my knowledge. Solving that problem in general is difficult if not
impossible. Not all terminals have line-drawing characters, and even those
that do don't have compatible characters in the same position in the
alternate character set.
> Does terminfo distinquish attribute modes by name rather than function.
> i.e. "Reverse video" rather than "stand-out mode" which might be "half
> intensity" for a different terminal.
"terminfo" has "enter_standout_mode" and "exit_standout_mode" capabilities
(which are, presumably, terminal-dependent in what they actually do, just as
in "termcap); it also has "enter_blink_mode", "enter_bold_mode",
"enter_dim_mode", etc. capabilities and their equivalent "exit"
capabilities. It also has a "set_attributes" capability which directly sets
video attributes. This capability is, in effect, the ANSI X3.64 Set Graphic
Rendition sequence (the "terminfo" capabilities mirror X3.64 control
sequences to a large degree).
> 3) nroff/troff and "man" command. I have none of these. I believe I heard
> that troff might be unbundled to either the documentor's workbench
> or writer's workbench...
They are unbundled in S5R2 distributions (i.e., you don't get *roff with an
S5R2 tape). I don't know how AT&T bundles it in binary distributions for
the 3Bs.
> 5) virtual memory/record locking - I understand that 5.2 does finally
> incorporate virtual memory but is that part of the requirements
> for ALL versions of 5.2?
S5R2 Version 2 (for the VAX) has virtual memory, but S5R2 Version 1 doesn't.
It is definitely NOT a requirement for all version of S5R2; what if you port
to a machine which can't support virtual memory?
> When (or if) the XENIX version that is 5.2 compatable on the IBM PC is
> implemented, will it support virtual memory...
Not bloody likely; the 808[68] can't support virtual memory (you can't trap
on a missing segment) and the 80286 can't support paged virtual memory, so
you won't see it on a non-AT PC and I don't think it's in the 80286
microport so you may not see it on an AT either.
> Likewise, will all record locking calls be supported identically on all
> 5.2 compatable versions?
Again, S5R2V2 on the VAX has the record locking calls, but S5R2V1 doesn't.
Any S5 based on the releases which have record locking will have compatible
versions.
> 9) Does anybody know if I can buy a CSH for the 3B2 from any source? I
> understand that the bourne shell under 5.2 has some job control
> finally (could somebody tell me how this interface works? Is it
> like the csh with ctl-z, fb, bg etc.?)
S5R2 doesn't have job control. It has "shell layers" which is basically a
window system except for the stuff that actually manages the screen; i.e.,
everything except the part that actually makes windows useful. You have N
(~7, I think) "layers" managed by a "window" manager called "shl". Each
layer has a pseudo-tty (or its moral equivalent) as its controlling TTY.
One layer is connected to your keyboard; whatever you type goes into its
pseudo-tty. All layers are connected to your screen/printhead, although you
can set "loblk" which is like "tostop" in that any attempt by a process
whose layer isn't the "current" layer causes the process to block. You type
^Z and the TTY switches to the layer manager's pseudo-tty; you then type
commands at the layer manager to switch the TTY to other layers.
The TTY's tty driver modes are the modes of whatever the "current" layer's
process has set them to, so if you switch from a layer in cooked mode to a
layer in character-at-a-time mode the modes switch automatically. However,
NO indication is given to a process that the TTY is being taken away from it
or given to it, so it can't clear the screen, or move the cursor to a
reasonable place, or take the terminal (as opposed to the TTY driver) out of
what funny mode it's put the terminal into (i.e., setting the keypad of a
VT100 to transmit numbers or escape sequences, putting a VT100 with a
graphics board into Tektronix 4014 or VT100 mode, etc.).
It's also not job control in that you can't stop a process and restart it
later; you can only take the terminal away from it and give it back later.
> but I desperately miss the history,
If you can get the Korn shell (AT&T permits a sublicensor to offer the Korn
shell in binary form with a system; they should take themselves up on that
offer and provide it with 3Bs), you can get history and ~ expansion. Also,
if you have source you can snarf the history mechanism for the S5R2 Bourne
shell that Arnold Robbins posted to net.sources; I've been using it and it's
very nice.
> push/pop directorys,
I think you can do this with shell functions - I think such a function was
posted by Robbins along with his other stuff.
> ~ expansion,
THe Korn shell and Robbins' changes to the Bourne shell have this.
(Unfortunately, I haven't been using it because it has to read the password
file itself - trying to use something that does "malloc"s inside the Bourne
shell is a headache, due to the way the Bourne shell manages its memory -
and on a Sun workstation running 2.0 or later most of the password file is
probably *not* on your machine but on a server so reading the password file
yourself doesn't help. Sigh...)
> and ctl-w word delete.
That's not a C shell feature, it's a tty driver feature. Having added it
(along with all the other Berkeley extensions) to the S5R2 driver I can
testify that it could be in S5R2. Unfortunately, it isn't.
Enough complains about this kind of stuff and AT&T might put it in - after
all, it worked with the Coca-Cola company...
Guy Harris
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!
decwrl!sun!gnu
From: g...@sun.uucp (John Gilmore)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <2423@sun.uucp>
Date: Tue, 16-Jul-85 05:24:59 EDT
Article-I.D.: sun.2423
Posted: Tue Jul 16 05:24:59 1985
Date-Received: Thu, 18-Jul-85 05:59:47 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 15
Ron Heiby at ihnp4!cuae2!heiby responded to a user's question "why doesn't
AT&T distribute [possibly optional] Berkeley enhancements, I hear they
use them in house anyway" with:
> As to any other BSD developments: They
> are all known of and looked at by AT&T developers. Some appear in System V,
> like "cat -v" and "ls -RadCxmnlogrtyucpFbqisf" and "mailx" (alias Mail). The
> thing to remember is that Berkeley is (supposed to be) in the education
> business. They do a good job by letting students experiment. AT&T is in the
> stable computing environment business. We do a good job by making darn sure
> that what we do doesn't break something (like a shell script or worse) and
> that we spend our efforts spending resources on the most important/needed
> enhancements first.
By implication that puts all commercial vendors of 4.2BSD systems
in the "unstable computing environment business"?
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site petrus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!
bellcore!petrus!hammond
From: hamm...@petrus.UUCP (Rich A. Hammond)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <406@petrus.UUCP>
Date: Wed, 17-Jul-85 08:07:47 EDT
Article-I.D.: petrus.406
Posted: Wed Jul 17 08:07:47 1985
Date-Received: Thu, 18-Jul-85 06:55:18 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
Organization: Bell Communications Research, Inc
Lines: 5
> By implication that puts all commercial vendors of 4.2BSD systems
> in the "unstable computing environment business"?
Judging by how often we find bugs and our machines crash, I'd say yes,
runnning 4.2 BSD is being in an unstable computing environment.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cuae2.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!mgnetp!hw3b!
wnuxb!cuae2!heiby
From: he...@cuae2.UUCP (Ron Heiby)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <371@cuae2.UUCP>
Date: Wed, 17-Jul-85 11:51:21 EDT
Article-I.D.: cuae2.371
Posted: Wed Jul 17 11:51:21 1985
Date-Received: Thu, 18-Jul-85 07:52:16 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
Reply-To: he...@cuae2.UUCP (Ron Heiby)
Organization: AT&T-IS, /app/eng, Lisle, IL
Lines: 18
In article <2...@sun.uucp> g...@sun.uucp (John Gilmore) writes:
>By implication that puts all commercial vendors of 4.2BSD systems
>in the "unstable computing environment business"?
There there, John. I was talking about the University of CA at Berkeley.
I was not talking about any commercial vendors. I have no knowledge of
Sun's quality control, although I have heard good reports from users
of Sun systems. BTW, in my previous job, I used a commercial port of
System III to a M68000 based system. The quality on that product was
marginal. So, I know enough not to be talking about quality of commercial
products based only on their porting base (although I have my favorite).
My remarks dealt only with the orientation of the organization that puts
out System V versus the organization that puts out BSD. Both are available.
It is up to the organization that purchases either to understand the
pros and cons involved. I'm sorry my remarks could have been mis-interpreted.
--
Ron Heiby he...@cuae2.UUCP (via ihnp4)
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version Tektronix Network News Daemon (B 2.10.2 based);
site daemon.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!
tektronix!daemon!davest
From: dav...@daemon.UUCP (Dave Stewart)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <964@daemon.UUCP>
Date: Thu, 18-Jul-85 12:27:34 EDT
Article-I.D.: daemon.964
Posted: Thu Jul 18 12:27:34 1985
Date-Received: Sun, 21-Jul-85 03:25:37 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
Reply-To: dav...@daemon.UUCP (Dave Stewart)
Organization: Tektronix, Beaverton OR
Lines: 19
In article <2...@sun.uucp> g...@sun.uucp (John Gilmore) writes:
>> ... We do a good job by making darn sure
>> that what we do doesn't break something (like a shell script or worse) and
>> that we spend our efforts spending resources on the most important/needed
>> enhancements first.
>
>By implication that puts all commercial vendors of 4.2BSD systems
>in the "unstable computing environment business"?
There are also plenty of examples where AT&T adds a BSD feature,
but changes the command or system call name or syntax. Isn't that
referred to as the NIH (Not Invented Here) syndrome? When will AT&T
(and DEC for that matter) realize that UC Berkeley is NOT a competitor?
Stepping down from his soapbox ...
--
David C. Stewart uucp: tektronix!davest
Small Systems Support Group csnet: davest@TEKTRONIX
Tektronix, Inc. phone: (503) 627-5418
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!gwyn
From: g...@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <46@brl-tgr.ARPA>
Date: Sun, 21-Jul-85 00:42:22 EDT
Article-I.D.: brl-tgr.46
Posted: Sun Jul 21 00:42:22 1985
Date-Received: Mon, 22-Jul-85 03:59:42 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<964@daemon.UUCP>
Organization: Ballistic Research Lab
Lines: 11
> There are also plenty of examples where AT&T adds a BSD feature,
> but changes the command or system call name or syntax. Isn't that
> referred to as the NIH (Not Invented Here) syndrome? When will AT&T
> (and DEC for that matter) realize that UC Berkeley is NOT a competitor?
There may be some "NIH" syndrome at work, but you should also appreciate
that BSD software is not necessarily up to commercial standards, so it
might need some adaptation before being supported by a commercial outfit.
Unfortunately, AT&T has been picking up some of the WORST features from
BSD. cat -v, ls -[a-z][A-Z], yuck.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site bu-cs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!bu-cs!root
From: r...@bu-cs.UUCP (Barry Shein)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
(absurdly long,sorry)
Message-ID: <514@bu-cs.UUCP>
Date: Sun, 21-Jul-85 14:48:21 EDT
Article-I.D.: bu-cs.514
Posted: Sun Jul 21 14:48:21 1985
Date-Received: Tue, 23-Jul-85 04:49:42 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<964@daemon.UUCP>,
<46@brl-tgr.ARPA>
Organization: Boston Univ Comp. Sci.
Lines: 121
>From: g...@brl-tgr.ARPA (Doug Gwyn <gwyn>)
>Subject: Re: instability in Berkeley versus AT&T releases
>> There are also plenty of examples where AT&T adds a BSD feature,
>> but changes the command or system call name or syntax. Isn't that
>> referred to as the NIH (Not Invented Here) syndrome? When will AT&T
>> (and DEC for that matter) realize that UC Berkeley is NOT a competitor?
>
>There may be some "NIH" syndrome at work, but you should also appreciate
>that BSD software is not necessarily up to commercial standards, so it
>might need some adaptation before being supported by a commercial outfit.
>
>Unfortunately, AT&T has been picking up some of the WORST features from
>BSD. cat -v, ls -[a-z][A-Z], yuck.
Ok Doug, it's fighting time. If by 'commercial standards' you mean
bug-free, I don't see where 4.2 has any corner on the bug market. For
example, you should see how many core-dumps per minute I get from sdb on
my 3B5 (the only debugger, no adb or dbx, this was under R1, maybe it
got better under R2, but maybe some bugs are out under 4.3, no?) It
won't even start about 25% of the time, just dies (yes, that's vanilla C
programs, trust me, its buggy as heck.)
And 3BNet...? C'mon, that's not a feature, that's a bug. How much does
dumb, incompatible, NIH design count? I mean, correct me if I'm wrong,
but doesn't networking have something to do with speaking to other
machines? I fought DECNET here, everyone fought SNA and now this? Ok,
they're gonna pick up TCP/IP cause now they got a $1Billion contract
from NSA, I'm glad, but I'm not impressed by the decision-making process.
As far as I can tell, you've got to have the sources to enable FLEXNAMES
(I do and am.) Unfortunately, I am still trying to re-build comp because
a source file is just missing. I understand the arguments to keep ids
down (and they're good arguments, I agree) but that's a funny compromise.
And things that are just plain missing that are mostly taken for granted
these days, like pty's (re: 4.2, VMS, tops-20)?? (forget sxts.)
And which file system is up to commercial standards? I think I have a
lot more faith in 4.2 than the SYSV 4.1 clone (how come 4.2 sites don't
even have an 'fsdb' [file sys debug], not because they never thought of
it, they really don't need it.)
And the back-up programs, what a joke, a complete and utter joke
compared to dump/restore on 4.2 (or is file system backup and retrieval
just not important to 'commercial' sites.) Follow the suggested backup
procedures in the administrators manual, now try to recover a lost file
(not file system, just one file.) Ooops, gotta know the inode number...
Oh yeah, what about file system quotas? Completely missing in SYSV
(except for the filesize limit, better than nothing I guess.) Or, again,
is avoiding filled file systems just not something of interest to
'commercial' environments. The administrator's manual suggests running
a job several times a day to check user's usage (I guess that's if you
still have room on the disk to run the program.)
And unbundling everything useful is a real strong point (hey, don't
worry about nroff bugs, you don't get nroff! bugs fixed.) Again, maybe I
read this wrong, maybe what I don't understand about commercial sites is
that they're too stupid to take something for free when they can pay
extra for the same thing. Along the same lines, should I tell my users
to use all the nifty graphics packages? Or as soon as they get them
debugged are they gonna unbundle them? Should I project my budget to
reflect paying unbundled prices for every piece of software on the
system that my users will end up screaming for? If unbundled nroff is
here, can 'cat' be far behind? How about the accounting package, backup
software, editors, mail system, make, sccs, games (what games?),
shl, help, terminfo, cpio, debuggers (what debuggers?), C, f77....
I think price predictability is of some importance to a commercial market.
Yeah, I know, how are they gonna make a living (poor AT&T.) On the other
hand, as I said when DEC handed me the same line about VMS utilities
(which are obscenely unbundled), ok, make a living off me not buying the
whole system then, if that's your plan. I believe I have pretty much
killed the idea of VMS workstations on this campus for that reason. Now
what am I gonna have to say about a 3B2 to remain consistent?
A -v arg to cat so it doesn't screw your terminal and a -C arg to ls so
you have a chance to to actually see more than 20 files, I can
understand your objections, but don't you think my list is a *little*
more important....honestly? (maybe that's what you meant.)
Ok, I *do* have a lot of faith in AT&T, I actually think as fast as you
are playing apologist they are filling in the gaps, I have heard very
solid rumours of a joint effort between AT&T and a 4.2 developer to just
finish the gap between the two once and for all. R2 was a huge
improvement over R1, I am very optimistic, and following SYSV right into
the whole 'phone system as network' technology coming up from AT&T
should be very exciting (not that 4.4BSD won't also have this :-)
They shouldn't be afraid to write 'unsupported' or 'not yet supported'
on a man page, it's a lot better than living without a feature for most
of us (probably not on a dump utility, but how about a csh or other
handy redundancies.)
Don't misunderstand me, I'll take SYSV over anything on the market...
except 4.2.
Hey, maybe B.U. just isn't a commercial site and doesn't understand?
But we have 2 3081s, a 4341, 19 vaxes, a 2060, 3B5, 3B2s etc etc,
a lot of the strategy recomendations come out of this office...do we
count too? How much of it is UNIX? not enough.
I think you asked for this. I also think too much of this appeared to be
pointed at you, this is actually a much broader shot.
-Barry Shein, Boston University
P.S. I may have made some small technical errors in my examples, we've
only had SYSV here a few months and R2 a couple of weeks (maybe you
*can* get a file off a backup tape by name, I couldn't see how.)
Let's try to stick to the big issues.
P.P.S. Hopefully, those at ATT who feel attacked will take this all as
constructive criticism and remember that *I* am the customer (and a
relatively happy one.)
P.P.P.S (this is getting obnoxious) Maybe it's time to form a good
ATTUS (analagous to DECUS.)
hi doug, you're the only one who got this far.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <5819@utzoo.UUCP>
Date: Tue, 23-Jul-85 13:02:52 EDT
Article-I.D.: utzoo.5819
Posted: Tue Jul 23 13:02:52 1985
Date-Received: Tue, 23-Jul-85 13:02:52 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
Organization: U of Toronto Zoology
Lines: 56
Come now, nobody said AT&T's stuff didn't have bugs, just that Berkeley
was worse. Which even some long-live-Berklix independents openly admit.
If you caught Clem Cole's discussion of software distribution at Masscomp
in the panel discussion at Usenix, you may have noted that he said there
was often a quandary about which version of a utility to pick: the one
from AT&T usually has more bugs fixed, while the one from Berkeley often
runs faster.
> And which file system is up to commercial standards? I think I have a
> lot more faith in 4.2 than the SYSV 4.1 clone (how come 4.2 sites don't
> even have an 'fsdb' [file sys debug], not because they never thought of
> it, they really don't need it.)
fsdb dates back to the days when *no* Unix filesystem was reliable, and
the automatic repair algorithms in fsck didn't exist. Its existence in
SysV is more likely to be a relic of the past than a real reflection of
need, since even the V7 file system essentially never needed patching
given fsck. (I speak as the sys admin of a V7 site, by the way.)
> Oh yeah, what about file system quotas? Completely missing in SYSV
> ... Or, again,
> is avoiding filled file systems just not something of interest to
> 'commercial' environments...
The lack of file system quotas probably reflects AT&T's openly-expressed
view (which I agree with) that except in special situations, if you think
you need disk quotas then you really need more disks instead. Situations
involving hostile users, e.g. undergrads, are obviously an exception --
note that this was the original motive for the 4.2 implementation of
quotas -- but how many businesses have that problem?
> And unbundling everything useful is a real strong point...
As many people have pointed out, unbundling (a) is a botch, and (b) is
necessary if you are selling Unix boxes with small disks. Not everybody
has Eagles to put it all on. Whether AT&T's unbundling strategy is
rational, even given this excuse, is another question... but it is not
totally without reason.
> ... maybe what I don't understand about commercial sites is
> that they're too stupid to take something for free when they can pay
> extra for the same thing...
Pray tell, how can a binary-only licensee (most commercial sites do not
have source, remember) get these things for free? I know quite a few
binary-only sites that would love to know.
> A -v arg to cat so it doesn't screw your terminal and a -C arg to ls so
> you have a chance to to actually see more than 20 files, I can
> understand your objections, but don't you think my list is a *little*
> more important....honestly?
Since I think both cat -v and ls -C are botches, I agree.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site baylor.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rochester!rocksanne!sunybcs!
kitty!baylor!peter
From: pe...@baylor.UUCP (Peter da Silva)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <307@baylor.UUCP>
Date: Wed, 24-Jul-85 15:31:23 EDT
Article-I.D.: baylor.307
Posted: Wed Jul 24 15:31:23 1985
Date-Received: Fri, 26-Jul-85 01:35:27 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<406@petrus.UUCP>
Organization: Ancient Illuminated Seers of Bavaria
Lines: 22
> > By implication that puts all commercial vendors of 4.2BSD systems
> > in the "unstable computing environment business"?
>
> Judging by how often we find bugs and our machines crash, I'd say yes,
> runnning 4.2 BSD is being in an unstable computing environment.
Judging by how much stuff Bell broke when they came out with SV, and judging by
the fact that BSD is still sufficiently compatible that you can run a
V6 binary on it (2BSD, but 2 is source compatible with 4), even if it
uses stty, I'd say it's Bell that's in the unstable computing environment
business.
System III.
System V, consider it standard.
System V, release 2, from now on consider it standard.
System V, release 2, Version 2?
--
-- Peter da Silva (the mad Australian)
-- UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
-- ARPA: baylor.pe...@RICE.ARPA
-- MCI: PDASILVA; CIS: 70216,1076; DELPHI: PJDASILVA
--
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <5827@utzoo.UUCP>
Date: Thu, 25-Jul-85 15:34:05 EDT
Article-I.D.: utzoo.5827
Posted: Thu Jul 25 15:34:05 1985
Date-Received: Thu, 25-Jul-85 15:34:05 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
Organization: U of Toronto Zoology
Lines: 11
> * Don't flame me if the index/strchr difference isn't an example of NIH --
> I haven't used V5 much...
I'd be suprised if you had, since V5 means "Version 5", which was a Bell
Labs (not USG) Unix around 1974. If you mean "System V", please say it
that way -- they are not the same thing.
"Calling System V `V5'?!? Them's fightin' words, bub!"
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!
decvax!decwrl!sun!guy
From: g...@sun.uucp (Guy Harris)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <2494@sun.uucp>
Date: Fri, 26-Jul-85 05:42:38 EDT
Article-I.D.: sun.2494
Posted: Fri Jul 26 05:42:38 1985
Date-Received: Sun, 28-Jul-85 05:39:39 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5819@utzoo.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 57
> ...a quandary about which version of a utility to pick: the one
> from AT&T usually has more bugs fixed, while the one from Berkeley often
> runs faster.
Which means, if the utility is important enough that it's worth the work,
the best strategy might be to "diff" the suckers and take the best from both
and put it into one version. (There is one utility where the one from AT&T
runs faster, and the one from Berkeley has more bugs fixed - "awk". The
S5R2 "awk" is quite a bit faster than all previous "awk"s, including the
4.2BSD one - one change is that it no longer uses structure-valued arguments
and functions - but it still has null-pointer-dereferencing bugs. We beat
those out of the 4.2BSD one...) (Then again, there are those utilities
where the only difference is the formatting of the code, or the presence,
absence, or shape of an SCCS ID - yes, there *are* utilities that haven't
changed since V7, as I know you're aware, but some people might be shocked
to hear that, especially the people who don't think AT&T had anything to do
with Berkeley UNIX...)
> The lack of file system quotas probably reflects AT&T's openly-expressed
> view (which I agree with) that except in special situations, if you think
> you need disk quotas then you really need more disks instead.
Maybe yes, maybe no. I think Parkinson's Law applies to disk space as well;
give users more disk space and they'll find some way to fill it, even if
they just fill it with "net.politics" archives.
Think of it as an economic
problem; you have a scarce resource, but the price mechanism has a long
time-scale over which it works - possibly too long to prevent short-term
space shortages. Quotas can keep users from eating the disks until you can
buy new ones, or until their managers get the bill for their disk space and
say "delete something or else". I'd be curious to know how many commercial
VMS sites, say, use the VMS disk quota mechanism? We've started to use disk
quotas here; we frequently have space problems. We had them at CCI as well.
CCI's customers also had them; our office automation systems were often sold
to people who weren't necessarily experienced system administrators, and who
may not really think about the fact that every big document they keep around
represents a document that some other user can't keep around. Again, there
are administrative techniques that can control disk usage over the long
term, but quotas can help deal with shortages in the short term.
> As many people have pointed out, unbundling (a) is a botch, and (b) is
> necessary if you are selling Unix boxes with small disks. Not everybody
> has Eagles to put it all on. Whether AT&T's unbundling strategy is
> rational, even given this excuse, is another question... but it is not
> totally without reason.
There's a difference between unbundling and charging separately; you can
provide a basic utility set and additional utilities as a single package, or
you can sell the additional utilities as add-ons. I believe it is the
latter policy that people object to. This policy is not a solution to the
technical problem of not having enough disk space to store all UNIX
utilities; it is a solution to the economic problem of paying for the
development and maintenance of software without charging people who have no
use for that software.
Guy Harris
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!decvax!decwrl!sun!guy
From: g...@sun.uucp (Guy Harris)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <2503@sun.uucp>
Date: Sat, 27-Jul-85 07:03:04 EDT
Article-I.D.: sun.2503
Posted: Sat Jul 27 07:03:04 1985
Date-Received: Sun, 28-Jul-85 06:22:06 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<406@petrus.UUCP>
<307@baylor.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 23
> Judging by how much stuff Bell broke when they came out with SV, and
> judging by the fact that BSD is still sufficiently compatible that you
> can run a V6 binary on it (2BSD, but 2 is source compatible with 4),
"V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6
(I think 1BSD was the V6 Berkeley distribution), but, more importantly, you
*can't* run V6 binaries on V7. You don't even have a good chance of
compiling *source* written for V6 on a V7 system and having it run.
And there are programs written for V7 that will break when you try to
compile them and run them under 4.2BSD...
> even if it uses stty, I'd say it's Bell that's in the unstable computing
> environment business.
If you're referring to the S3 terminal driver, from Bell's standpoint they
didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or
whatever the hell the release before UNIX 3.0 was). The trouble is that the
release that went out the door before System III was V7, not UNIX 2.0, which
means the S3 driver's backward compatibility with UNIX 2.0 is totally
useless to anybody outside the former Bell System.
Guy Harris
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!decvax!decwrl!sun!guy
From: g...@sun.uucp (Guy Harris)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <2505@sun.uucp>
Date: Sat, 27-Jul-85 07:14:48 EDT
Article-I.D.: sun.2505
Posted: Sat Jul 27 07:14:48 1985
Date-Received: Sun, 28-Jul-85 06:22:49 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5827@utzoo.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 16
> > * Don't flame me if the index/strchr difference isn't an example of NIH --
> > I haven't used V5 much...
>
> I'd be suprised if you had, since V5 means "Version 5", which was a Bell
> Labs (not USG) Unix around 1974. If you mean "System V", please say it
> that way -- they are not the same thing.
Furthermore, the index/strchr difference is probably not an example of NIH
in the way the original poster thought. *Both* routines are products of
AT&T - the routine was called "index" in V7 and "strchr" in System III. At
what point it was renamed, I dunno. The S3 documentation comes with a
description of changes between S3 and some unspecified earlier version of
UNIX. One of the changes was that "strcpyn" was renamed "strncpy". This
predates V7, since it was called "strncpy" there as well.
Guy Harris
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site phri.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!
talcott!panda!genrad!decvax!tektronix!uw-beaver!cornell!vax135!timeinc!
phri!roy
From: r...@phri.UUCP (Roy Smith)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <349@phri.UUCP>
Date: Sat, 27-Jul-85 12:14:32 EDT
Article-I.D.: phri.349
Posted: Sat Jul 27 12:14:32 1985
Date-Received: Wed, 31-Jul-85 03:18:00 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5819@utzoo.UUCP>
Followup-To: net.unix-wizards
Organization: Public Health Research Inst. (NY, NY)
Lines: 14
Keywords: cat -v, ls -C
> ... I think both cat -v and ls -C are botches ...
> Henry Spencer @ U of Toronto Zoology
Why is "cat -v" a botch? If you want to see if you have junk in a
file it's a lot nicer than "od -c". And what's so terrible about "ls -C"?
The multi-column format is much nicer, and it turns out that most of the
time it does the right thing (i.e. picks 1-column vs. multi-column mode).
Oh, BTW, for you net.micro.att readers, note that I've added a
Followup-To: net.unix-wizards line.
--
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!Glacier!mips!mash
From: m...@mips.UUCP (John Mashey)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (really index)
Message-ID: <153@mips.UUCP>
Date: Mon, 29-Jul-85 00:43:57 EDT
Article-I.D.: mips.153
Posted: Mon Jul 29 00:43:57 1985
Date-Received: Tue, 30-Jul-85 05:32:48 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5827@utzoo.UUCP> <2505@sun.uucp>
Organization: MIPS Computer Systems, Mountain View, CA
Lines: 33
Guy Harris writes (onto long sequence of articles):
> > > * Don't flame me if the index/strchr difference isn't an example of NIH --
> > > I haven't used V5 much...
>
> Furthermore, the index/strchr difference is probably not an example of NIH
> in the way the original poster thought. *Both* routines are products of
> AT&T - the routine was called "index" in V7 and "strchr" in System III. At
> what point it was renamed, I dunno. The S3 documentation comes with a
> description of changes between S3 and some unspecified earlier version of
> UNIX. One of the changes was that "strcpyn" was renamed "strncpy". This
> predates V7, since it was called "strncpy" there as well.
0) As usual, Guy has pretty good model of the history, minor details:
1) index->strchr happened in UNIX/TS 1.0 (in some sense, System I of the System
V sequence). My 1.0 manual reads November 78; as I recall, this particular
change happened fairly early in the packaging effort that was trying to
get Edition 7 (late, but not released), PWB/UNIX 1.2, and some USG G3
UNIX all back together.
2) strcpyn ->strncpy happened at the same time, early 78. The rename
was because some non-UNIX systems (GCOS, I think) took only the first
6 characters, so that strcpy and strcpyn conflicted, a clearly bad thing.
3) In general, it is unwise to EVER label something as NIH unless you know
for a fact that it is NIH. There are more weird reasons for things being
different in different UNIX versions than you would ever believe; only a few
of them are NIH; it is always best to ask why things are different.
--
-john mashey
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD: 415-960-1200
USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!Glacier!mips!mash
From: m...@mips.UUCP (John Mashey)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <154@mips.UUCP>
Date: Mon, 29-Jul-85 01:03:19 EDT
Article-I.D.: mips.154
Posted: Mon Jul 29 01:03:19 1985
Date-Received: Tue, 30-Jul-85 05:33:20 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<406@petrus.UUCP> <307@baylor.UUCP> <2503@sun.uucp>
Organization: MIPS Computer Systems, Mountain View, CA
Lines: 35
> > even if it uses stty, I'd say it's Bell that's in the unstable computing
> > environment business.
>
> If you're referring to the S3 terminal driver, from Bell's standpoint they
> didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or
> whatever the hell the release before UNIX 3.0 was). The trouble is that the
> release that went out the door before System III was V7, not UNIX 2.0, which
> means the S3 driver's backward compatibility with UNIX 2.0 is totally
> useless to anybody outside the former Bell System.
1) PWB/UNIX 2.0 was the release before, and before that was UNIX/TS 1.0
(Nov 78). Both of these still had stty/gtty in section (2), with ioctl(3),
with everybody warned to switch over.
2) It is always worth remembering:
a) Research versions of ANYTHING have no commitment whatsoever to
upward compatibility (whether from ATT, UCB, or anywhere else). Once
they do that, the research content falls off pretty badly. Back in
the real old days when we got releases straight from 127, we were
happy when something was upward compatible, but certainly didn't
expect it.
b) Supported versions that do have such commitments must play by
radically different rules, which make them take longer to do:
1) Worry about major customers [for example, as I recall,
the ioctl stuff came from CB/UNIX, or Operations Systems Unices
in general, because the V6/V7 stuff wasn't quite enough.
Remember that such Unices paid the bills for a long time.
2) Never add anything that you not sure of lasting for a while,
because you do have the commitment to keep it semi-forever.
3) Work very hard on transition aids and strategies.
--
-john mashey
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD: 415-960-1200
USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <5838@utzoo.UUCP>
Date: Mon, 29-Jul-85 16:46:26 EDT
Article-I.D.: utzoo.5838
Posted: Mon Jul 29 16:46:26 1985
Date-Received: Mon, 29-Jul-85 16:46:26 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5819@utzoo.UUCP> <2494@sun.uucp>
Organization: U of Toronto Zoology
Lines: 35
> Which means, if the utility is important enough that it's worth the work,
> the best strategy might be to "diff" the suckers and take the best from both
> and put it into one version.
Also important is to take the worst from both and *not* put it into the
new version.
> > The lack of file system quotas probably reflects AT&T's openly-expressed
> > view (which I agree with) that except in special situations, if you think
> > you need disk quotas then you really need more disks instead.
>
> ...Think of it as an economic
> problem; you have a scarce resource, but the price mechanism has a long
> time-scale over which it works - possibly too long to prevent short-term
> space shortages. Quotas can keep users from eating the disks until you can
> buy new ones...
The AT&T observation was not that there is no reason for quotas, but that
(like password aging) they don't work satisfactorily. If you can *impose*
quotas on your user community, you can make them work. If users can argue
with the quotas, then you're sunk, because the sum total of the quotas that
users feel they can live with probably exceeds the size of the disk. That
is, if disk space is short enough that you *need* quotas, it's probably
overcommitted already. My own experience with space-short systems certainly
supports this claim. There is also the related problem of maxima becoming
minima: "I'm under my quota, so I don't need to clean up yet".
I have no personal experience with quota systems, but I really wonder if
they aren't like password aging: a superficially-plausible idea that
doesn't really work all that well.
Hostile users are another story, of course.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site kitty.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rochester!rocksanne!sunybcs!
kitty!peter
From: pe...@kitty.UUCP (Peter DaSilva)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <197@kitty.UUCP>
Date: Wed, 31-Jul-85 12:14:55 EDT
Article-I.D.: kitty.197
Posted: Wed Jul 31 12:14:55 1985
Date-Received: Fri, 2-Aug-85 08:18:46 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<406@petrus.UUCP>
<307@baylor.UUCP> <2503@sun.uucp>
Organization: Recognition Research Corp., Clarence, NY
Lines: 39
> > [ME]
> [Guy Harris]
[Me: second try at replying]
> > Judging by how much stuff Bell broke when they came out with SV, and
> > judging by the fact that BSD is still sufficiently compatible that you
> > can run a V6 binary on it (2BSD, but 2 is source compatible with 4),
>
> "V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6
I know. I was referring to the V7 system as 2BSD, not the V6 one. I know what
2- and 4- BSD are. Hell, some of my code went out in one of the releases (I've
seen it at IUVAX).
> (I think 1BSD was the V6 Berkeley distribution), but, more importantly, you
> *can't* run V6 binaries on V7. You don't even have a good chance of
> compiling *source* written for V6 on a V7 system and having it run.
At Berkeley there were several V6 programs that there was no source to. They
were running on a 2BSD system (ucbcory). QED.
> And there are programs written for V7 that will break when you try to
> compile them and run them under 4.2BSD...
Actually once you change RAW to CBREAK they're quite compatible. I've moved
stuff between V5, V6, and V7 with few problems. SIII and SV are a royal pain,
though.
> > even if it uses stty, I'd say it's Bell that's in the unstable computing
> > environment business.
>
> If you're referring to the S3 terminal driver, from Bell's standpoint they
> didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or
> whatever the hell the release before UNIX 3.0 was). The trouble is that the
> release that went out the door before System III was V7, not UNIX 2.0, which
> means the S3 driver's backward compatibility with UNIX 2.0 is totally
> useless to anybody outside the former Bell System.
And since most real world UNICES are V7 derived, what does that say about Bell?
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site sjuvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!sjuvax!jss
From: j...@sjuvax.UUCP (J. Shapiro)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <1227@sjuvax.UUCP>
Date: Thu, 1-Aug-85 00:55:05 EDT
Article-I.D.: sjuvax.1227
Posted: Thu Aug 1 00:55:05 1985
Date-Received: Sat, 3-Aug-85 01:46:42 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5819@utzoo.UUCP>
<349@phri.UUCP>
Organization: Haverford College, Haverford, Pa.
Lines: 12
> > ... I think both cat -v and ls -C are botches ...
> > Henry Spencer @ U of Toronto Zoology
>
> And what's so terrible about "ls -C"?
> Roy Smith <allegra!phri!roy>
The only thing terrible about ls -C is that it ought to be the default for
CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_
brain damaged.
Jon Shapiro
Haverford College
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <5852@utzoo.UUCP>
Date: Thu, 1-Aug-85 13:19:37 EDT
Article-I.D.: utzoo.5852
Posted: Thu Aug 1 13:19:37 1985
Date-Received: Thu, 1-Aug-85 13:19:37 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5819@utzoo.UUCP>,
<349@phri.UUCP>
Organization: U of Toronto Zoology
Lines: 18
Keywords: cat -v, ls -C
> Why is "cat -v" a botch? If you want to see if you have junk in a
> file it's a lot nicer than "od -c". And what's so terrible about "ls -C"?
Nobody is arguing that the functionality isn't useful; it's just misplaced.
Funny-character expansion doesn't belong in cat any more than it belongs
in cp or tar; it should be a separate command. Columnizing doesn't belong
in ls any more than it belongs in spell or grep; it should be a separate
command. It is obviously useful to be able to invoke a columnizing ls
with one command, but that's a trivial shell file (or an alias, for those
who run shells that start up slowly and hence can't run small shell files
efficiently); there is no need to build it into ls.
For an explanation of why "one program, one function, done well" is a good
way to build a system, see almost any discussion of the "Unix philosophy".
Try Kernighan & Pike.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!carroll
From: carr...@utcsri.UUCP (Eric Carroll)
Newsgroups: net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <1303@utcsri.UUCP>
Date: Thu, 1-Aug-85 20:11:19 EDT
Article-I.D.: utcsri.1303
Posted: Thu Aug 1 20:11:19 1985
Date-Received: Thu, 1-Aug-85 22:36:13 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5819@utzoo.UUCP>
<349@phri.UUCP> <5852@utzoo.UUCP>
Reply-To: carr...@utcsri.UUCP (Eric Carroll)
Organization: CSRI, University of Toronto
Lines: 43
Keywords: Unix philosophy
Summary:
In article <5...@utzoo.UUCP> he...@utzoo.UUCP (Henry Spencer) writes:
>
> For an explanation of why "one program, one function, done well" is a good
> way to build a system, see almost any discussion of the "Unix philosophy".
> Try Kernighan & Pike.
> --
> Henry Spencer @ U of Toronto Zoology
> {allegra,ihnp4,linus,decvax}!utzoo!henry
_Software Tools_, pg. 84 (Kernighan & Pike):
Efficiency is hardly of importance for a temporary hookup
meant only to be used a few times. Should a particular
organization of tools prove so useful that it begins to
consume significant resources, then you can consider
replacing it with a more efficient version. And you are
way ahead at this point, for you are writing a program
that has precise specifications and that has been shown
to be useful.
I think columnar ls is a case in point, though perhaps a bit trivial to
really worry about. From the human perspective, it is much more
pleasant, and doesn't waste my time scrolling the listing off the
screen. And if it is used heavily, why not incorporate it? I agree with
modular, single function boxes, but there should be some quarter given
to practicality here; if it is used heavily, that is your license to
incorporate it into the code. I won't argue the more esoteric features
of ls. The point is, I think, that there are several levels of use:
One-function boxes strung together with pipes, shell scripts, and for
the most heavily used features that have made it to the level of
'heavily used shell scripts', C coding, or inclusion into an existing
binary program. I see no justification for the religious statement
"Thou shalt code in sh." It is a relative, sliding scale that leaves
room for things like Berkley ls. Not to say that they have never
over-done it, mind you...
--
----
Regards,
Eric Carroll
Univ of Toronto, Computer Systems Research Institute
{allegra, decvax, decwrl, floyd, ihnp4, linus}!utcsri!carroll
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!decvax!genrad!
panda!talcott!harvard!seismo!brl-tgr!gwyn
From: g...@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <408@brl-tgr.ARPA>
Date: Sat, 3-Aug-85 22:43:23 EDT
Article-I.D.: brl-tgr.408
Posted: Sat Aug 3 22:43:23 1985
Date-Received: Tue, 6-Aug-85 06:02:10 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5819@utzoo.UUCP>
<349@phri.UUCP> <1227@sjuvax.UUCP>
Organization: Ballistic Research Lab
Lines: 9
> The only thing terrible about ls -C is that it ought to be the default for
> CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_
> brain damaged.
I would sure get upset if when I ran "ls" in the long skinny window
on my DMD, it didn't print the file names one per line. You are
making the same mistake that a lot of the more crufty BSD software
has made, namely: assuming an overly-restrictive model of how the
software is to be used.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site osu-eddie.UUCP
Path: utzoo!watmath!clyde!cbosgd!osu-eddie!cbrma!kk
From: k...@cbrma.UUCP
Newsgroups: net.micro.att
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <521@osu-eddie.UUCP>
Date: Sun, 4-Aug-85 11:27:15 EDT
Article-I.D.: osu-eddi.521
Posted: Sun Aug 4 11:27:15 1985
Date-Received: Mon, 5-Aug-85 07:51:48 EDT
Sender: u...@osu-eddie.UUCP
Organization: Ohio State Univ., CIS Dept., Cols, Oh.
Lines: 54
From: cbrma!kk
> > If you're referring to the S3 terminal driver, from Bell's standpoint they
> > didn't break anything. it's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or
> > whatever the hell the release before UNIX 3.0 was). The trouble is that the
> > release that went out the door before System III was V7, not UNIX 2.0, which
> > means the S3 driver's backward compatibility with UNIX 2.0 is totally
> > useless to anybody outside the former Bell System.
> And since most real UNICES are V7 derived, what does that say about Bell?
Um, I'd like to bring this point in question for just a second. Although I
work for Bell, I am neither (a) defending my company nor (b) trying to convince
anybody that S3/S5 is better/worse than BSD/V7. I just want to question the
statement that most UNICES are V7-derived. This is basically
numbers-juggling, since the complaint is based on `most UNICES.'
I work at Columbus Bell Labs. My department has something like 60 people in
it. We have 2 VAX 780s, 2 PDP-11/70s, 1 3B, 7 PDP-11/73s, 6 PDP-11/23+'s,
and 6-or-so PDP-11/23s. My understanding (more or less confirmed by my
local sysadmin) is that my department is not particularly equipment-rich with
respect to processors. All of our processors run USG Unix systems, i.e., S3
or S5. There are, in turn, around 550 people (last I heard) working here at
Columbus BL. Scaling up my department's systems to account for the rest of
the systems at this location means that there are in the vicinity of
200 processors running Unix systems around here.
It is of course important that not all of them are running USG Unix systems;
the obvious case in point is that Mark Horton works (lives?) somewhere on the
next floor down, and his department works primarily with BSD, I guess; knock
off a dozen processors for those VAXen and SUNs, and maybe another half dozen
for some other department's systems that I don't know anything about. But I
think the wide majority can be said to be running non-BSD stuff.
My major point is this: Columbus is far from the largest of the Bell Labs
locations; we're only a `branch' location anyway. There are something like
5000 people in the Indian Hill area, and I don't even want to guess who's in
NJ. I'm aware of a sysadmin in Indian Hill who has responsibility for 28 VAXen
on one floor alone. Try scaling those kinds of numbers up to account for
who's running what version of the Unix system; I think it'll alarm you.
Thus, I don't think it's reasonable or fair to say that most Unix systems
are V7-derived. Just dealing with our own internal systems, it's nowhere
near true, and I haven't even made the faintest attempt to consider outside
customers who are buying S5 at a substantial pace. And, further, maintaining
compatibility for all those folks who were doing things in UNIX 2.0 or
PWB/UNIX x.x (long, long before I showed up here) was a substantial concern.
Just a thought for reflection...someone will probably flame me anyway with
`Yeah, but my company runs these <n> Widget-62s that are so popular and use
BSD'...sigh.
[This is probably completely unrelated to company position, of course.]
--
Karl Kleinpaste
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site kitty.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rochester!rocksanne!sunybcs!
kitty!peter
From: pe...@kitty.UUCP (Peter DaSilva)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <247@kitty.UUCP>
Date: Mon, 5-Aug-85 17:14:06 EDT
Article-I.D.: kitty.247
Posted: Mon Aug 5 17:14:06 1985
Date-Received: Wed, 7-Aug-85 02:46:19 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<5819@utzoo.UUCP>
<349@phri.UUCP> <1227@sjuvax.UUCP> <408@brl-tgr.ARPA>
Organization: Recognition Research Corp., Clarence, NY
Lines: 7
> I would sure get upset if when I ran "ls" in the long skinny window
> on my DMD, it didn't print the file names one per line. You are
Then why don't YOU alias "ls | cat" and let the majority of the world work.
It's these weird variants put in for esoteric special cases that really
bugs me about SV. How many AT&T 7300s are going to benefit from SV accounting
stuff?
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.14 $; site siemens.UUCP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!edsel!bentley!ihnp1!
ihnp4!mhuxn!mhuxr!ulysses!allegra!princeton!siemens!haahr
From: ha...@siemens.UUCP
Newsgroups: net.unix-wizards
Subject: Re: instability in Berkeley versus A
Message-ID: <93600010@siemens.UUCP>
Date: Mon, 5-Aug-85 11:41:00 EDT
Article-I.D.: siemens.93600010
Posted: Mon Aug 5 11:41:00 1985
Date-Received: Tue, 6-Aug-85 09:58:58 EDT
References: <1303@utcsri.UUCP>
Lines: 103
Nf-ID: #R:utcsri:-130300:siemens:93600010:000:5299
Nf-From: siemens!haahr Aug 5 11:41:00 1985
> > For an explanation of why "one program, one function, done well" is a good
> > way to build a system, see almost any discussion of the "Unix philosophy".
> > Try Kernighan & Pike.
> > --
> > Henry Spencer @ U of Toronto Zoology
> > {allegra,ihnp4,linus,decvax}!utzoo!henry
>
> _Software Tools_, pg. 84 (Kernighan & Pike):
Hate to be picky, but _Software_Tools_ was written by Kernighan and P. J.
Plauger (of Whitesmiths). But it is a great source for Unix philosophy.
> Efficiency is hardly of importance for a temporary hookup
> meant only to be used a few times. Should a particular
> organization of tools prove so useful that it begins to
> consume significant resources, then you can consider
> replacing it with a more efficient version. And you are
> way ahead at this point, for you are writing a program
> that has precise specifications and that has been shown
> to be useful.
>
> I think columnar ls is a case in point, though perhaps a bit trivial to
> really worry about. From the human perspective, it is much more
> pleasant, and doesn't waste my time scrolling the listing off the
> screen. And if it is used heavily, why not incorporate it? ...
The definitive argument against Berkeley ls is in _Program_Design_in_
_the_UNIX_System_Environment_, by (would you believe) Kernighan & Pike,
BSTJ, October 1984, specifically pages 1601-1603. To quote: (note that
the authors refer to Berkeley ls as lsc)
Surprisingly, lsc operates differently if its output is a file
or a pipe:
lsc
produces output different from
lsc | cat
The reason is that lsc begins by examining whether its output is
a terminal, and prints its output in columns only if it is. By
retaining single-column output to files or pipes, lsc retains
compatibility with programs like grep or wc, which expect things
to be printed one per line...
A more insidious problem with lsc is the columnation facility,
which is actually a useful, general function, is built in and thus
inaccessible to other programs that could use a similar compression.
The authors then suggest a general purpose filter (based on pr) that would
take its output and columnate it. So, for five-column output from ls:
ls | 5
On your concern for efficiency, the only avoidable answer is yes, the
two command version is slower and does involve more typing. On typing,
create a shell script ll (or whatever) that does
ls $* | 5
or, for people who like to see /*=@ etc after filenames
ls -F $* | 5
If your shell provides aliasing or shell functions this is even easier.
This is, of course, slower than Berkeley ls, except ls wouldn't have to
check where it's output is going (one isatty call), so a vanilla ls
piping its output to grep will work faster. Plus, for a command that
is executed interactively (I can think of very few occasions when one would
want to have columnar ls output to a terminal from something that is
time critical), I would doubt that the big problem comes from between pipes
I have tried using an 'll' which is a csh alias for a pipe and can't notice
difference (VAX-11/750, unloaded). My point here is basically that you
are talking about gaining a trivial amount efficiency in exchange for
elegance and simplicity.
> ... I agree with
> modular, single function boxes, but there should be some quarter given
> to practicality here; if it is used heavily, that is your license to
> incorporate it into the code. I won't argue the more esoteric features
> of ls. The point is, I think, that there are several levels of use:
> One-function boxes strung together with pipes, shell scripts, and for
> the most heavily used features that have made it to the level of
> 'heavily used shell scripts', C coding, or inclusion into an existing
> binary program. I see no justification for the religious statement
> "Thou shalt code in sh." It is a relative, sliding scale that leaves
> room for things like Berkley ls. Not to say that they have never
> over-done it, mind you...
They have overdone it all too often it seems. If Berkeley had provided a
general purpose columnation command (even better if it was termcap
sensitive rather than fixed 80-columns) and had found that a lot of
people had aliases or shell scripts that piped ls to this program and
found a way to keep it compatible with existing use (I don't like having
programs like ls checking if their output is a terminal) and there was
a big win in speed observed by hacking the code into ls, then, yes, maybe
they should do ls -C, but the Berkeley approach seems to be: gee, output
from ls (and no other program? :-) runs off the screen a lot. Why don't
I fix (break?) ls so that doesn't happen. But I don't want to affect
any program that looks at ls, only what a user sees. And only if they
decide not to use a filter like more for those really large directories.
The Berkeley philosophy is reminiscent of the FORTRAN programmer in
_Software_Tools_'s first chapter, who has the clever idea of not using
a red pencil to find all FORMAT statements in his program, but instead
writes a program that searches for the word FORMAT. Now that they have
proven that columnation of output is useful, why not provide a general
purpose way of doing it?
Paul Haahr
..!allegra!princeton!macbeth!haahr
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!
decwrl!sun!guy
From: g...@sun.uucp (Guy Harris)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <2567@sun.uucp>
Date: Tue, 6-Aug-85 03:54:39 EDT
Article-I.D.: sun.2567
Posted: Tue Aug 6 03:54:39 1985
Date-Received: Sat, 10-Aug-85 04:58:27 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<406@petrus.UUCP>
<307@baylor.UUCP> <2503@sun.uucp> <197@kitty.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 73
> At Berkeley there were several V6 programs that there was no source to. They
> were running on a 2BSD system (ucbcory). QED.
That's nice. They sure as hell didn't use "seek" or "stat"...
> > And there are programs written for V7 that will break when you try to
> > compile them and run them under 4.2BSD...
>
> Actually once you change RAW to CBREAK they're quite compatible.
I'll assume this statement refers to V6 vs. V7; I hope nobody is ignorant
enough to think CBREAK was a Berkeley invention...
> I've moved stuff between V5, V6, and V7 with few problems.
Bet you had fun with the stuff using the old V5/V6 I/O library which was not
available in V7...
> SIII and SV are a royal pain, though.
Only if you don't know what you're doing. I've moved stuff between V7 and
S3/S5 with few problems.
In case you're curious, I once (as a hack) got most of the way through
turning V7 kernel source into S3 kernel source, working with on-line V7
source and an S3 kernel printout. I submit that the chances of a V6 binary
running on S3/S5 are very close to the chances of a V6 binary running on V7
(PDP-11 binaries here - although, from a quick look at the system call and
"exec" code of S5R2 and 4.2BSD, the chances look *very* good that you can
run many S5 binaries under 4.2BSD!). At least V7's "lseek" and "stat" calls
are the same in S5... (if I had a V6 manual, I'd check to see how compatible
the V6 and V7 drivers' "sgtty" structures were, and then check how
compatible the V6 and PWB/UNIX 2.0 structures - as used by S5 - were...)
Then again, you can't run PDP-11 *or* VAX binaries on the 4.2BSD machine I'm
typing this on, so the question of binaries is irrelevant anyway...
Moving on to sources, I merely state again that I've moved code between V7,
4.2BSD, and S5 with few hard glitches. Converting "ioctl"s is certainly
tedious, but *if* you know what you're doing there are few surprises. Of
course, a number of flamers against the S3/S5 driver haven't bothered doing
the work of figuring out the (admittedly complex) interface...
(BTW, try porting an S5, S3 *or* V7 program which expects "read", "write",
"wait", etc. system calls to be interrupted by signals to 4.2BSD. You may
get a little surprise...)
> > ...the S3 driver's backward compatibility with UNIX 2.0 is totally
> > useless to anybody outside the former Bell System.
>
> And since most real world UNICES are V7 derived, what does that say about
> Bell?
It says that due to a mixture of technical and legal reasons they couldn't
a) throw away the 2.0 compatibility in S3 replacing it with V7 compatibility
or b) offer two versions of UNIX 3.0.1/S3.
As for your claim that "most real world UNICES are V7 derived", I don't
believe it. Period. Most commercial vendors are offering S3 or S5-based
systems. Several 4.2 vendors are now offering 4.2BSDs that have some degree
of S5 compatibility. Some of them are even clever enough to offer 4.2
functionality and S5 compatibility to the same programs as opposed to
walling the two systems off in separate worlds. I suspect this will happen
more in the future.
I think enough has been said - more than enough, since most of the postings
on this subject have been broadsides fired in religious wars rather than
accurate discussions of the places where {V7,4.2BSD,S5} do well and where
they do poorly. If anybody else wants to wage holy war over why their
favorite version of UNIX is the "only true UNIX", could they please move the
discussion to net.flame or net.religion.software?
Guy Harris
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!
decwrl!Glacier!mips!mash
From: m...@mips.UUCP (John Mashey)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <161@mips.UUCP>
Date: Thu, 8-Aug-85 03:08:14 EDT
Article-I.D.: mips.161
Posted: Thu Aug 8 03:08:14 1985
Date-Received: Mon, 12-Aug-85 00:30:45 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
Organization: MIPS Computer Systems, Mountain View, CA
Lines: 63
> > > ...the S3 driver's backward compatibility with UNIX 2.0 is totally
> > > useless to anybody outside the former Bell System.
> >
> > And since most real world UNICES are V7 derived, what does that say about
> > Bell?
>
> It says that due to a mixture of technical and legal reasons they couldn't
> a) throw away the 2.0 compatibility in S3 replacing it with V7 compatibility
> or b) offer two versions of UNIX 3.0.1/S3.
I can't remember any legal reasons. The technical reason was real simple:
remember that UNIX/TS -> PWB 2.0 -> SIII ->SV was a convergence process
to desperately try to get a UNIX that more people could agree
on and avoid having to make weird extensions; terminal driver was a notorious
area for such extensions; too many people doing non-research projects found
they needed other things. Again, ANYONE WHO EXPECTS TO GET UPWARD-COMPATIBLE
RELEASES FROM SOMETHING LABELED RESEARCH does not understand research.
Research versions of things and production, guaranteed-upward-compatible
things are different animals [not better or worse, just different].
>
> As for your claim that "most real world UNICES are V7 derived", I don't
> believe it. Period. Most commercial vendors are offering S3 or S5-based
> systems. Several 4.2 vendors are now offering 4.2BSDs that have some degree
> of S5 compatibility. Some of them are even clever enough to offer 4.2
> functionality and S5 compatibility to the same programs as opposed to
> walling the two systems off in separate worlds. I suspect this will happen
> more in the future.
I wish someone could quote numbers here; "most real world UNICES are V7 derived"
is certainly true, since XENIX, V and 4.2 are all V7-derived. In the more
specific sense of "V7, rather than III", this is probably true [numbers,
somebody?] because I suspect there are a lot of V7-derived XENIX systems
still out there [by sheer numbers of CPUs]. By number of users, who knows?
>
> I think enough has been said - more than enough, since most of the postings
> on this subject have been broadsides fired in religious wars rather than
> accurate discussions of the places where {V7,4.2BSD,S5} do well and where
> they do poorly. If anybody else wants to wage holy war over why their
> favorite version of UNIX is the "only true UNIX", could they please move the
> discussion to net.flame or net.religion.software?
Yes!! It is often more prudent to ask why a (dumb) decision was made than
to flame upon its stupidity; sometimes environments and tradeoffs are
different and you learn something. Some of the "X is better than Y"
arguments are really "[in my situation] X is better than Y [and I don't
have much experience with other kinds of situations] and therefore people
who use Y must be communist mutants from space [or worse!]
Here's a test case: how many people think UNIX is better than IBM's OS/MVS?
....
If you answered:
-What do you want to use it for? 10 points - good answer.
-What's MVS? 5 points for honesty.
-UNIX is better, of course - MVS is UGLYYYYY. - 0 points [because what you
get to do is a 10 Gigabyte database with required response times that
and needs a 3084.] Don't laugh; I've known people who tried to put
projects like that on UNIX; not too many worked.
Much insight can come from tradeoff analysis; sometimes by looking at
differences we learn what the real general cases are and make progress
by synthesizing better mechanisms that cover more cases; little
progress is made in religious wars.
--
-john mashey
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD: 415-960-1200
USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!
decvax!decwrl!Glacier!mips!mash
From: m...@mips.UUCP (John Mashey)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <162@mips.UUCP>
Date: Thu, 8-Aug-85 03:33:43 EDT
Article-I.D.: mips.162
Posted: Thu Aug 8 03:33:43 1985
Date-Received: Mon, 12-Aug-85 00:31:18 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
Organization: MIPS Computer Systems, Mountain View, CA
Lines: 36
> Then why don't YOU alias "ls | cat" and let the majority of the world work.
> It's these weird variants put in for esoteric special cases that really
> bugs me about SV. How many AT&T 7300s are going to benefit from SV accounting
> stuff?
"Weird variants put in for esoteric special cases..." is a pejorative
description that could be read "I don't need this so it's dumb". A better
way to have written this might be: "Does anyone know why SYS V accounting
is included in the system? We haven't seen any use for it in our environment,
and it seems particularly unnecessary for single-user workstations. Who
uses it?"
Now, the true facts [and I wrote it, so I know] are:
a) It is (correctly) in the Optional part of the SYS V spec.
b) Computer centers do like to be able to usage accounting so they
can charge people money. This might not make sense if you've never
used a computer center or run one, but it is true.
c) Various people sometimes like to analyze system performance
and usage [without actually charging people] by looking at
the accounting output.
V6 shell accounting was [in practice] found to be inadequate for real
computer centers; there was a major push by BTL computer centers starting
about 1977 to offer UNIX; we therefore tried hard to get a minimal
mechanism to become part of V7 [many thanks to DMR for cooperation here]
that would satisfy b) and c) above to avoid having every comp center
do their own thing; the original version had to work on both V6 and V7's;
had to work on PDP-11s; had to be a toolkit to adapt to different people's
ideas of charging algorithms; ought to be reworked because requirements
have changed!
Weird? Esoteric? No, just different needs.
--
-john mashey
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD: 415-960-1200
USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!linus!gatech!cbosgd!mark
From: m...@cbosgd.UUCP (Mark Horton)
Newsgroups: net.micro.att
Subject: Re: instability in Berkeley versus AT&T releases
Message-ID: <1379@cbosgd.UUCP>
Date: Thu, 8-Aug-85 21:22:50 EDT
Article-I.D.: cbosgd.1379
Posted: Thu Aug 8 21:22:50 1985
Date-Received: Sun, 11-Aug-85 06:25:55 EDT
References: <521@osu-eddie.UUCP>
Followup-To: mod.unix
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 53
In article <5...@osu-eddie.UUCP> cbrma...@osu-eddie.UUCP writes:
Sheesh! What does all this have to do with AT&T micros?
Can't we move this discussion to, say, mod.unix?
>the obvious case in point is that Mark Horton works (lives?) somewhere on the
>next floor down, and his department works primarily with BSD, I guess; knock
>off a dozen processors for those VAXen and SUNs,
Lest anyone get the wrong impression, we have only 4 4.2BSD machines in
our dept - one VAX, one Sun fileserver, and two Sun workstations. The
rest of the machines mostly run System V (except for a Masscomp which is
SIII derived, two SIII based HP machines, and a 6300 that runs Xenix.)
Our project is committed to System V too.
And strangely enough, I do go home a lot. Sometimes I get more work
done from home than my office (and sometimes vice versa.) I can produce
a lot nicer environment in my office at home than AT&T provides there.
(Haven't figured out how to take my Sun workstation home yet, though.)
>I just want to question the
>statement that most UNICES are V7-derived. This is basically
>numbers-juggling, since the complaint is based on `most UNICES.'
Well, I could probably say just about anything here and produce a
statistic to back it up.
In terms of pure numbers, my understanding is that over half of the
UNIX systems in the world today run Xenix. Since Xenix is V7
derived (with lots of System III and V stuff added in later) it
can be reasonably said that ``most unices are V7-derived''
However, most Xenix machines are micros or even PC's, so this
number can be misleading. Most of these machines don't connect
into the net as we see it. (Whether such connection matters is
no doubt part of your definition of "real world", which is certainly
subject to some creative wording.)
Another way of looking at it is this. Of about 2500 known machines
on the UUCP network (not counting the various machines that we've just
"heard of" but don't really know anything about), about half of them
are owned by AT&T, and about half are in the outside world. And it's
certainly true that most of AT&T has System V colored glasses on
(internally it isn't even called System V, it's called "Standard UNIX",
at least when spoken this is the term I usually hear.) There are a few
pockets of 4.2BSD, but even these pockets tend to have lots of System V
machines around too. So, assuming there are even a few System V machines
outside AT&T, if you count the machines that are well enough known to
be on UUCP, System V would win (and System V is NOT V7-derived.) Note
that the typical 3B2 or UNIX PC or Xenix machine is NOT on the map,
and believe me, there are gobs and gobs of them up and down the halls
(not to mention the 6300's that people use as terminals.)
Mark Horton
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ncoast.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!
cwruecmp!hal!ncoast!bsa
From: b...@ncoast.UUCP (Brandon Allbery)
Newsgroups: net.unix-wizards
Subject: ls holy wars
Message-ID: <834@ncoast.UUCP>
Date: Mon, 12-Aug-85 22:02:51 EDT
Article-I.D.: ncoast.834
Posted: Mon Aug 12 22:02:51 1985
Date-Received: Sun, 18-Aug-85 20:50:33 EDT
References: <1303@utcsri.UUCP> <93600010@siemens.UUCP>
Reply-To: b...@ncoast.UUCP (Brandon Allbery)
Followup-To: net.unix-wizards
Organization: North Coast Xenix, Cleveland, OH
Lines: 88
Expires:
Quoted from <93600...@siemens.UUCP> ["Re: instability in Berkeley versus A"],
by ha...@siemens.UUCP...
+---------------
| > I think columnar ls is a case in point, though perhaps a bit trivial to
| > really worry about. From the human perspective, it is much more
| > pleasant, and doesn't waste my time scrolling the listing off the
| > screen. And if it is used heavily, why not incorporate it? ...
|
| The definitive argument against Berkeley ls is in _Program_Design_in_
| _the_UNIX_System_Environment_, by (would you believe) Kernighan & Pike,
| BSTJ, October 1984, specifically pages 1601-1603. To quote: (note that
| the authors refer to Berkeley ls as lsc)
|
| Surprisingly, lsc operates differently if its output is a file
| or a pipe:
| lsc
| produces output different from
| lsc | cat
| The reason is that lsc begins by examining whether its output is
| a terminal, and prints its output in columns only if it is. By
| retaining single-column output to files or pipes, lsc retains
| compatibility with programs like grep or wc, which expect things
| to be printed one per line...
| A more insidious problem with lsc is the columnation facility,
| which is actually a useful, general function, is built in and thus
| inaccessible to other programs that could use a similar compression.
|
| The authors then suggest a general purpose filter (based on pr) that would
| take its output and columnate it. So, for five-column output from ls:
| ls | 5
|
lots of nonsense
|
| The Berkeley philosophy is reminiscent of the FORTRAN programmer in
| _Software_Tools_'s first chapter, who has the clever idea of not using
| a red pencil to find all FORMAT statements in his program, but instead
| writes a program that searches for the word FORMAT. Now that they have
| proven that columnation of output is useful, why not provide a general
| purpose way of doing it?
Fine, so write a general purpose one.
First, let me reiterate: MOST UNIX MACHINES ARE
NNNN NNN OOOOOOOOOOOOOOOO TTTTTTTTTTTTTTTTTTTT
NNNNN NNN OOOOOOOOOOOOOOOOOO TTTTTTTTTTTTTTTTTTTT
NNNNNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNN NNN OOO OOO TTT
NNN NNNNNN OOO OOO TTT
NNN NNNNN OOOOOOOOOOOOOOOOOO TTT
NNN NNNN OOOOOOOOOOOOOOOO TTT
V A X E N !
(Excuse the length; but this is a VERY VERY SORE POINT! ! ! ! ! ! ! !)
Our TRS-80 Model 16 can NOT NOT NOT run a shell script ANYWHERE as fast as
a C program. ls | pr -t -5 takes FOREVER to run! And the Plexus P/35 is
not a whole lot faster.
Now before some well-meaning computer junkie tells me that we should get Vaxen,
please look at the price tag on yours.
Now before you suggest piped stuff for ls or any other program where columnar
output is COMMONLY USED to a terminal, remember that if DEC went out of busi-
ness, the Unix community would live on through the 68000. The business world
cannot afford Vaxen!
--bsa
--
Brandon Allbery, Unix Consultant -- 6504 Chestnut Road, Independence, OH 44131
decvax!cwruecmp!ncoast!bsa; ncoast!...@case.csnet; +1 216 524 1416; 74106,1032
-- --
"Well, we can't go dragging around the universe with a dormant Gravis on the
console!" --Tegan, FRONTIOS
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <5877@utzoo.UUCP>
Date: Wed, 14-Aug-85 14:15:30 EDT
Article-I.D.: utzoo.5877
Posted: Wed Aug 14 14:15:30 1985
Date-Received: Wed, 14-Aug-85 14:15:30 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<1392@cbosgd.UUCP>
Organization: U of Toronto Zoology
Lines: 14
> ... From the implementers
> viewpoint, it's simpler to have it run down the left margin. From the
> novice user's viewpoint, it's simpler to have it appear in columns on
> the side of the screen than to (a) learn to lunge for ^S before it runs
> off the screen, (b) remember to type -C every time, or (c) learn how to
> make a .profile that contains the function.
From *both* viewpoints, it is simpler to have pagination available in the
tty driver. This means that the implementors don't have to kludge it into
every program, and the users need neither lightning reflexes nor high
sophistication. Try it, you'll like it.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!linus!gatech!cbosgd!mark
From: m...@cbosgd.UUCP (Mark Horton)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <1408@cbosgd.UUCP>
Date: Sun, 18-Aug-85 01:14:52 EDT
Article-I.D.: cbosgd.1408
Posted: Sun Aug 18 01:14:52 1985
Date-Received: Mon, 19-Aug-85 22:17:52 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<1392@cbosgd.UUCP> <5877@utzoo.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 13
In article <5...@utzoo.UUCP> he...@utzoo.UUCP (Henry Spencer) writes:
>From *both* viewpoints, it is simpler to have pagination available in the
>tty driver. This means that the implementors don't have to kludge it into
>every program, and the users need neither lightning reflexes nor high
>sophistication. Try it, you'll like it.
We have page mode in our tty driver too. I agree that it's a win to have
page mode. However, in the specific case of the ls command, it's still
much better to have it come out in columns. It's really useful to be
able to see the entire directory at once, instead of having to look at it
in snippets of 24 lines.
Mark
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards
Subject: Re: ls holy wars
Message-ID: <5892@utzoo.UUCP>
Date: Tue, 20-Aug-85 19:30:07 EDT
Article-I.D.: utzoo.5892
Posted: Tue Aug 20 19:30:07 1985
Date-Received: Tue, 20-Aug-85 19:30:07 EDT
References: <1303@utcsri.UUCP> <93600010@siemens.UUCP>, <834@ncoast.UUCP>
Organization: U of Toronto Zoology
Lines: 32
> Our TRS-80 Model 16 can NOT NOT NOT run a shell script ANYWHERE as fast as
> a C program. ls | pr -t -5 takes FOREVER to run! ...
>
> Now before some well-meaning computer junkie tells me that we should get
> Vaxen, please look at the price tag on yours.
>
> Now before you suggest piped stuff for ls or any other program where columnar
> output is COMMONLY USED to a terminal, remember that if DEC went out of busi-
> ness, the Unix community would live on through the 68000. The business world
> cannot afford Vaxen!
Repeat after me:
"There is no such thing as a free lunch."
We can't afford a VAX either. But our lousy little 11/44 runs shell scripts
briskly. Partly because we have a high-performance shell; partly because we
gritted our teeth, recited "you get what you pay for", and spent some money
on good disk drives. Which are available for many, many 68000 boxes too.
It really should come as no surprise that you have to bend your software
out of shape if it has to run quickly on slow hardware. This sort of nasty
pragmatic necessity should not be confused with fundamental principles of
good software design.
Actually, I have no objection to writing a C program that implements the
equivalent of "ls | pr -t -5"; it is a fairly common wish. I'll probably
do it here someday. But I won't call the result "ls", and it won't try
to guess where its output is headed and alter the output on that basis.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site frog.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!cybvax0!frog!rfm
From: r...@frog.UUCP (Bob Mabee)
Newsgroups: net.unix-wizards
Subject: Pagination in TTY driver
Message-ID: <280@frog.UUCP>
Date: Wed, 21-Aug-85 21:30:18 EDT
Article-I.D.: frog.280
Posted: Wed Aug 21 21:30:18 1985
Date-Received: Sat, 24-Aug-85 17:52:24 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<1392@cbosgd.UUCP>
<5877@utzoo.UUCP>
Organization: Charles River Data Systems, Framingham MA
Lines: 22
{}
(referring to novice and expert users of ls)
> From *both* viewpoints, it is simpler to have pagination available in the
> tty driver. This means that the implementors don't have to kludge it into
> every program, and the users need neither lightning reflexes nor high
> sophistication. Try it, you'll like it.
> --
> Henry Spencer @ U of Toronto Zoology
This sounds like a fruitful topic of discussion. I would like to see this
become a "standard extension" like file locking.
Please tell us more about your user interface. Do you require a Y every
23 lines of output? Only after 23 lines without intervening input (so
you never notice pagination while running less verbose commands?
What are the drawbacks? Do "portable" UNIX programs have to be modified
to disable pagination for editing, communications, etc? Does the TTY
driver have to decode cursor motion sequences (as Multics did)?
--
Bob Mabee @ Charles River Data Systems
decvax!frog!rfm
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site rna.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!
seismo!cmcl2!rna!dan
From: d...@rna.UUCP (Dan Ts'o)
Newsgroups: net.unix-wizards
Subject: Re: Pagination in TTY driver
Message-ID: <435@rna.UUCP>
Date: Sun, 25-Aug-85 14:02:46 EDT
Article-I.D.: rna.435
Posted: Sun Aug 25 14:02:46 1985
Date-Received: Tue, 27-Aug-85 01:45:41 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<1392@cbosgd.UUCP>
<5877@utzoo.UUCP> <280@frog.UUCP>
Reply-To: d...@rna.UUCP (Dan Ts'o)
Organization: Rockefeller Neurobiology
Lines: 49
In article <2...@frog.UUCP> r...@frog.UUCP (Bob Mabee) writes:
>{}
>(referring to novice and expert users of ls)
>> From *both* viewpoints, it is simpler to have pagination available in the
>> tty driver. This means that the implementors don't have to kludge it into
>> every program, and the users need neither lightning reflexes nor high
>> sophistication. Try it, you'll like it.
>> --
>> Henry Spencer @ U of Toronto Zoology
>
>This sounds like a fruitful topic of discussion. I would like to see this
>become a "standard extension" like file locking.
>
>Please tell us more about your user interface. Do you require a Y every
>23 lines of output? Only after 23 lines without intervening input (so
>you never notice pagination while running less verbose commands?
Also:
What about terminals that don't have 24 lines ? Some have
16 and some have 66 ? Do you have yet another ioctl() ?
What happen when you print lines that wrap around the screen ?
Does the kernel know how to count character spacing, know the screen width,
whether the terminal has AM and XN and account for it when making page breaks ?
The better pagers allow reverse and forward viewing. I find
this capability indispensible. Do you plan to add a buffer in the kernel to
allow reviewing of previous lines ?
Does your implementation handle well situations where the
application is sending more than 24 lines but since it is using cursor
addressing, it is self consistent ? Does your kernel recognize cursor motion
sequences or do you have to turn off paging every time you run such an
application ? (e.g. graphics, some screen editors) Maybe you expect such
applications to run in RAW or CBREAK and don't do paging in those modes, or
maybe you expect such applications to shut off paging themselves.
Yes, I know paging works fine for many situations.
Cheers,
Dan Ts'o
Dept. Neurobiology
Rockefeller Univ.
1230 York Ave.
NY, NY 10021
212-570-7671
...cmcl2!rna!dan
rna!...@cmcl2.arpa
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards
Subject: Re: Pagination in TTY driver
Message-ID: <5911@utzoo.UUCP>
Date: Mon, 26-Aug-85 17:24:10 EDT
Article-I.D.: utzoo.5911
Posted: Mon Aug 26 17:24:10 1985
Date-Received: Mon, 26-Aug-85 17:24:10 EDT
References: <928@brl-tgr.ARPA>, <6594@boring.UUCP>
Organization: U of Toronto Zoology
Lines: 70
This article is a collection of replies to several comments on in-kernel
tty paging.
> You mean like on TOPS-20? Where it seems the tty drivers use TERMCAP or an
> equivalent (if you type more than 1 line & hit ^U it cursors to the beginning
> of the input line (maybe several terminal lines above) and sends a CL sequence!
Interesting, but it has nothing to do with output pagination.
> Please tell us more about your user interface. Do you require a Y every
> 23 lines of output? Only after 23 lines without intervening input (so
> you never notice pagination while running less verbose commands?
Glossing over a few fine points, any time 22 lines of output are seen
without any intervening input, the tty driver stops and waits for a RETURN.
(Actually any input character will do, but RETURN arriving while the tty
is in a paging wait cancels the wait and disappears, while anything else
cancels the wait and sticks around.) No, the "22" is not burned into the
kernel, it is set by an ioctl, generally to a number ultimately derived
from termcap.
> What are the drawbacks?
The only significant thing we've found is that it's hard to get line-wrap
handling 100% right.
> Do "portable" UNIX programs have to be modified
> to disable pagination for editing, communications, etc?
No, switching to CBREAK or RAW mode turns it off implicitly. The only
things we have modified (except our kernel) are stty to know about the
paging ioctl, getty's terminal initialization to set the defaults right
(from termcap, by the way), and our local pager program "p" to exploit
kernel paging if it's on. Nothing else.
> Does the TTY
> driver have to decode cursor motion sequences (as Multics did)?
No.
> [a similar scheme...]
> ^S turns pagination mode on and suspends output
> ^Q turns pagination mode off and resumes output
Wrong choice of control characters. Nowadays one must assume that ^S
and ^Q are strictly, completely, and entirely reserved for flow control
between the terminal and the host. We had a bug in this in our early
versions, in fact.
One thing which we do find valuable is a control character (settable via
the paging ioctls, default ^T) which turns paging off until the next
input character. This lets you disable paging temporarily for something
like verbose program output that you don't want to see in detail. The
ability to do this conveniently is important.
> The
> advantage of not having pagination in the kernel is the ability to have
> tailored paginators.
Agreed. But for most people, a poor pager that's built in generally beats
a wonderful pager that always has to be invoked explicitly. I dislike
building things like this into the kernel; there really ought to be some
way to run all one's terminal i/o through a central agent without having
to build the agent into the kernel. Doing that efficiently isn't simple.
We decided that an ugly implementation now beat a clean one five years
down the road. We were right.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site aphasia.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!cybvax0!frog!
aphasia!gww
From: g...@aphasia.UUCP (George Williams)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <302@aphasia.UUCP>
Date: Mon, 26-Aug-85 18:06:58 EDT
Article-I.D.: aphasia.302
Posted: Mon Aug 26 18:06:58 1985
Date-Received: Fri, 30-Aug-85 11:37:28 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<1392@cbosgd.UUCP> <5877@utzoo.UUCP>
Organization: Green Hills Software, Pasadena, CA
Lines: 31
> From *both* viewpoints, it is simpler to have pagination available in the
> tty driver. This means that the implementors don't have to kludge it into
> every program, and the users need neither lightning reflexes nor high
> sophistication. Try it, you'll like it.
> --
> Henry Spencer @ U of Toronto Zoology
> {allegra,ihnp4,linus,decvax}!utzoo!henry
One problem with pagination in the tty driver:
At caltech we have a network that lives between most computers and
most terminals, now unfortunately the network uses ^S/^Q (of course)
and any ^S, ^Q you type on your terminal will go to the network
not to the computer. So putting pagination in the tty driver
really confuses novice users, the documentation says that pressing
^Q gets things started again, but it doesn't. Instead they have
to rummage arround, find the network documentation (which is not
written for novices) find that what they really want is ^P^Q.
I admit that I found this very useful when playing on a twenty
many years ago, but when I started using our network I discovered
that about half the lines I logged into had old processes hanging
arround that just needed a ^P^Q typed on them.
There must be a better soln. somewhere.
George Williams
cit-vax!aphasia!gww
the moon is nothing
But a circumambulating aphrodisia
Divinely subsidized to provoke the world
Into a rising birth-rate
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards
Subject: Re: Pagination in TTY driver
Message-ID: <5915@utzoo.UUCP>
Date: Tue, 27-Aug-85 12:48:30 EDT
Article-I.D.: utzoo.5915
Posted: Tue Aug 27 12:48:30 1985
Date-Received: Tue, 27-Aug-85 12:48:30 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
Organization: U of Toronto Zoology
Lines: 49
> What about terminals that don't have 24 lines ? Some have
> 16 and some have 66 ? Do you have yet another ioctl() ?
The size is of course set by ioctl, since no way would we consider
imbedding something like that into the kernel.
> What happen when you print lines that wrap around the screen ?
> Does the kernel know how to count character spacing, know the screen width,
> whether the terminal has AM and XN and account for it when making page breaks ?
This is somewhat of a headache. The kernel is *already* counting character
spacing, please note, so that's not an issue. It gets it right for the
simple cases, and most non-simple cases want to use CBREAK mode anyway.
The ioctl includes an indication of screen width. The AM/XN mess is not
yet fully accounted for, although there's nothing impossible about doing so.
(Before people start moaning about how unUnixish it is to put such things
into the kernel, check out the definition of newline delay type 1. Such
details of terminal handling have a long history of being in the kernel!)
> The better pagers allow reverse and forward viewing. I find
> this capability indispensible. Do you plan to add a buffer in the kernel to
> allow reviewing of previous lines ?
This, we have not done; it would be a major added complication. We find
the in-kernel pager very useful without it. We agree that the in-kernel
pager is not the answer to all mankind's problems, or even all Unix's
pagination problems. We are not convinced that "more" and its kin do in
fact represent such an answer, either!
> Does your implementation handle well situations where the
> application is sending more than 24 lines but since it is using cursor
> addressing, it is self consistent ? Does your kernel recognize cursor motion
> sequences or do you have to turn off paging every time you run such an
> application ? (e.g. graphics, some screen editors) Maybe you expect such
> applications to run in RAW or CBREAK and don't do paging in those modes, or
> maybe you expect such applications to shut off paging themselves.
Our experience has been that such applications invariably run in CBREAK
or RAW; paging is applicable only to COOKED mode. This was a slightly
ad-hoc decision that has worked very well in practice. We are opposed on
principle to having an unbounded number of programs know about paging.
> Yes, I know paging works fine for many situations.
That it does. We do still have explicit pager programs, but they get far
less use nowadays.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 5/22/85; site cbosgd.UUCP
Path: utzoo!watmath!clyde!cbosgd!mark
From: m...@cbosgd.UUCP (Mark Horton)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: page mode in the tty driver
Message-ID: <1454@cbosgd.UUCP>
Date: Mon, 2-Sep-85 16:32:34 EDT
Article-I.D.: cbosgd.1454
Posted: Mon Sep 2 16:32:34 1985
Date-Received: Tue, 3-Sep-85 04:30:21 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>
<1392@cbosgd.UUCP>
Organization: AT&T Bell Laboratories, Columbus, Oh
Lines: 48
In article <3...@aphasia.UUCP> g...@aphasia.UUCP (George Williams) writes:
>One problem with pagination in the tty driver:
> At caltech we have a network that lives between most computers and
> most terminals, now unfortunately the network uses ^S/^Q (of course)
> and any ^S, ^Q you type on your terminal will go to the network
> not to the computer. So putting pagination in the tty driver
> really confuses novice users, the documentation says that pressing
> ^Q gets things started again, but it doesn't. Instead they have
> to rummage arround, find the network documentation (which is not
> written for novices) find that what they really want is ^P^Q.
There are many ways to implement page mode in the tty driver. In UNIX,
it turns out to be very convenient to put it right next to the xon/xoff
code, which does a similar thing. (This is the reason given by most of
the people who feel page mode should not be in the system, since xon/xoff
is implemented in each separate device driver rather than the tty driver
proper, you have to hack each new device driver to support page mode.
The same argument could be made that xon/xoff should not be supported by
the UNIX system either, but it's already there.)
If you do the quick-and-dirty page mode implementation, then typing ^Q
is one way to get it started again after you are at the bottom of a page.
However, this doesn't work well, if you have a terminal that uses xon/xoff
heavily, you may find the terminal sends the ^Q that lets it go on to the
next page when you weren't done reading the last one.
To do it properly, you have to present the interface that xon/xoff is a
flow control level used only by your terminal to keep its buffers from
overflowing. Page mode, on the other hand, is a user visible feature
which is different from xon/xoff. You use a different character (we
use space) to let it go another page. Typing ^Q at a stopped page doesn't
do anything, but then typing ^Q when the system is prompting you for
input doesn't do anything either - your terminal might have sent the ^Q.
The problem of users getting confused doesn't really happen, because
(and this is the beauty of page mode) the users never need to know
about ^S/^Q! Lunging for the ^S key to read something that's about
to go off the screen is not necessary, the system will stop automatically.
The users only need to know about the space bar, and since page mode is
set up so that ANY character (other than those eaten by the flow control
level) will wake it up, hung terminals never happen. (By convention,
the character typed is still passed through to the program reading from
the tty, except that a space typed while stopped in page mode is tossed.)
I have yet to have any of our users get confused, nor do I ever find a
terminal hung waiting for a space. And we have lots of users who are
new to the UNIX system here.
Mark