instability in Berkeley versus AT&T releases
John Gilmore
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"?
Rich A. Hammond
> 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.
Ron Heiby
>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
Dave Stewart
>> 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
Guy Harris
John didn't say "by implication that says 4.2BSD is an unstable computing
environment", he said "by implication that puts all *commercial* vendors of
4.2BSD systems in the 'unstable computing environment business'." My
machine is supplied by a "commercial vendor of 4.2BSD systems" (as is
John's, I suspect :-) :-) :-)), and, well,
4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00
It's been up longer. The only times it's crashed due to an OS bug are a few
times when some pre-release software hung and it had to be rebooted (that
problem hasn't recurred, and it wasn't the 4.2BSD base's fault) and once
when it crashed due to some code I'd added (which, for the benefit of those
of you who sneer at "lint", would have been reported by "lint"ing the
kernel).
I've rarely found bugs, and most of them have been pretty small. (Several
pieces of code from the System V release would have crashed on this machine,
because they dereference null pointers, so the Berkeley people aren't the
only people who ship buggy UNIX software.)
Then again, the "stability" being discussed here is not resistance to
crashes but the absence of system changes that break existing code. Yes,
4.2BSD has introduced some changes which break existing code. So has System
V. (Remember the time they decided to enforce the "only one external
definition" rule? The old COMMON-block semantics came back faster than Old
Coke...)
Guy Harris
Doug Gwyn <gwyn>
> 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.
Jim Gettys
>...................................................... My
>machine is supplied by a "commercial vendor of 4.2BSD systems" (as is
>John's, I suspect :-) :-) :-)), and, well,
>
> 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00
>
>It's been up longer. The only times it's crashed due to an OS bug are a few
>times when some pre-release software hung and it had to be rebooted (that
>problem hasn't recurred, and it wasn't the 4.2BSD base's fault) and once
>when it crashed due to some code I'd added (which, for the benefit of those
>of you who sneer at "lint", would have been reported by "lint"ing the
I have seen an amusing bug in ruptime on our machines here (running a
"not commercially supported" version of 4.2).
mit-zeus up ??+17:42, 0 users, load 0.01, 0.03, 0.03
This occurs if a machine has been up more than 99 days......
Several other machines on that local net had been up over 80 days, so
it was not a fluke. Unfortunately, we had a power failure at 111 days.
Sigh.... I suppose we should all get up on our high horses and swear
at Berkeley for "buggy" software, but I for one am willing to forgive
them for this particular bug.
Jim Gettys
Project Athena
Barry Shein
>Subject: Re: instability in Berkeley versus AT&T releases
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.
Jim Hutchison
>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).
Sir, BSD's spring from the loins of version 7. System V is of system III,
hint think death star. :-)
--
/*
Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch
ARPA: hutch@sdcsvax
[ Of course, these statements were typed into my terminal while I was away. ]
*/
Brad Davis
crashes the operating system with a
panic error: out of swap space
main()
{
while (malloc(1024)) ;
}
Don't have any problem with our BSD 4.2 1/2 Vax though.
(HP says it will be fixed in the next release that we
don't have yet.)
--
Brad Davis
{ihnp4, decvax, seismo}!utah-cs!b-davis
b-d...@utah-cs.ARPA
Doug Gwyn <gwyn>
> >> 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.
>
Hey, Barry, all I was saying is that it isn't a crime for AT&T to change
some aspects of the code that they borrow from 4BSD when they integrate
it into their product. I agree that there have been some very stupid
decisions made in the UNIX System V packaging as well as some good ones.
I am glad that they're making an effort to organize the UNIX package.
I agree that there is no real networking (by Internet standards) in the
AT&T product yet. TCP/IP is long overdue, but it is certainly not the
ideal. AT&T has promised full ISO protocols implemented with streams,
and have demonstrated a prototype full-semantics (unlike NFS) transparent
remote filesystem which is expected to appear in their product "soon".
I don't have 3Bs, so I don't know why you're having problems with the SGS.
Our DMD SGS works fine. I thought flexnames were a standard feature now.
Ptys should appear along with stream I/O, where they can be done right.
The 4.2BSD "fast file system" is unnecessarily complex; AT&T is rumored
to have a simple implementation of a fast file system. I don't know
whether it fragments big blocks. It is funny that you take AT&T to task
for providing "fsdb" and fault them for not providing other things..
4.2BSD backup and restore is certainly an improvement over old tools.
To their credit, AT&T has been improving many of the system administration
procedures. Perhaps they will pick up on this one.
The right way to implement file system quotas is subject to debate. I
have been burned by the 4.2BSD scheme, which has some real lossages..
Unbundling is a sore point. Seems that what is really needed is a way
for VARs/OEMs to sell packaged systems for minimal licensing fees, while
end-users get a "rich" set of utilities in their basic package, in order
to ensure that they have what is needed to support add-on software.
I think the main problem is that AT&TIS sees themselves in the "iron"
(computer hardware) business, not the information business. I hope they
can see that UNIX is much more than just a 3B operating system. I note
that they're dropping the VAX from future releases; is DEC going to fill
in for them or are they going to keep Ultrix a 4BSD look-alike (or both)?
The PWB/Graphics and Plot facilities are scheduled to be replaced by
something else, probably based on GKS. Specs have not yet been published.
I don't have any real stake in "playing apologist" for AT&T. I too have
chastised them publicly for their mistakes. I do think, however, that
there are better performance metrics than the degree to which they lift
pieces of 4BSD unmodified.
I hope the rumors of convergence between 4.nBSD and System V are true;
otherwise, 4BSD's days are numbered. I've been doing my bit to help
bring about such a merger, which does not necessarily mean that there
would not continue to be two distinct systems for the different target
user populations (research vs. commercial). The biggest roadblock to
4.nBSD migrating in a System V direction seems to have been the silly
policy that AT&T now has of not permitting exchange of UNIX-derived
software among source UNIX licensees who have different CPU types.
I agree fully with AT&T's position that there should not be two flavors
of standard shell. It looks like the Korn shell may filter into the
AT&T product (other than as a ToolChest add-on); if so, there would be
little reason to ask for a Cshell. Ksh is very nice, is Bourne shell
compatible, and does everything the Cshell can do.
An AT&T UNIX user's group that could exert pressure for wanted goodies
might be a good idea. The existing UNIX groups do not seem to fulfill
this role.
> hi doug, you're the only one who got this far.
Hi, Barry! Let's hope the AT&T UNIX policy makers are listening, too.
Henry Spencer
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
Tom Faulhaber
> > > By implication that puts all commercial vendors of 4.2BSD systems
> > > in the "unstable computing environment business"?
> John's, I suspect :-) :-) :-)), and, well,
>
> 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00
>
I am afraid that this is the point that proves the argument. We have
an Ethernet composed of Convergent MiniFrames (the parent of the PC 7300)
in Un*x engineering at CT. A few days ago an ruptime display would have
shown you that the Networking development machine (mine) and the OS development
machine had been up for 45 days. These machines had rebooted after PG&E
decided to run over one of the power lines to our building. Unfortunately last
week they ran over the power lines again! I would note that the OS
development machine was running the latest CTIX version, and the networking
machine was running an experimental kernel.
I say this only partially to brag about our systems. Primarily, I would like
point out that five or even fifteen days of uptime does not make a solid
operating system.
Tom Faulhaber
...decwrl!greipa!tommif!tom
P.S. Of course, we run System V.
Westerman
>
>P.P.P.S (this is getting obnoxious) Maybe it's time to form a good
>ATTUS (analagous to DECUS.)
>
Yes, let's form ATTUS. As I see it, AT&T is our only hope to get UNIX
out of being a much talked about OS into being a much used OS.
Whom: Rick Westerman Phone: +1-317-494-8344
UUCP: {decvax, ihnp4, seismo, ucbvax}!pur-ee!westerm
USPS: Ag Data Network, Purdue University, West Lafayette IN 47907
A proud owner of a 3b2, but a *user* of 4.2 ---> "4.2 > V"
Peter da Silva
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...@RICE.ARPA
-- MCI: PDASILVA; CIS: 70216,1076; DELPHI: PJDASILVA
--
Larry Campbell
> 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?
Hostile users aren't the only good reason to have quotas. What about
buggy software that gets into an infinite loop writing to a file?
It's pretty annoying that such a bug can essentially crash (i.e., make
useless) a timesharing system.
> 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...
I thought unbundling was done mainly to reduce the entry-level price
of a Unix license. After all, you could always ship everything and let
the user decide which pieces to devote disk space to. (And I agree --
unbundling is a botch.)
> --
> Henry Spencer @ U of Toronto Zoology
> {allegra,ihnp4,linus,decvax}!utzoo!henry
Larry Campbell decvax!genrad
The Boston Software Works, Inc. \
120 Fulton St. seismo!harvard!wjh12!maynard!campbell
Boston MA 02109 / /
ihnp4 cbosgd
ARPA: decvax!genrad!wjh12!maynard!camp...@DECWRL.ARPA
Doug Gwyn <gwyn>
UNIX 3.0
> System V, consider it standard.
UNIX 5.0 (4.0 was not released for public licensing)
> System V, release 2, from now on consider it standard.
UNIX 6.0, until AT&T decided to establish "UNIX System V" as
a recognized symbol. Now UNIX 5.2
> System V, release 2, Version 2?
This has been a remarkably upward-compatible evolutionary path.
5.2.2 added demand paging (much cleaner than 4BSD's) and
record locking (more general than either 4BSD or /usr/group)
without visibly changing the semantics of already-existing
facilities. This is the way it should be.
Both 4BSD and UNIX System V have good and bad points and both
have unnecessarily broken things in new releases. The main
advantage of System V (notice that "UNIX" is omitted here)
with regard to stability is that all significant commercial
UNIX and C standardization efforts are adhering closely to it
(and vice-versa).
Could we go on to more productive topics?
Henry Spencer
> 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!"
Guy Harris
> hint think death star. :-)
Umm, err, V7 also came out of the death star, although it came from a
different place therein. S3 came from a slightly pre-V7 release (*much
much* closer to V7 than to V6).
Then again, you can't hold AT&T (from whose code *all* the aforementioned
UNIXes ultimately derives) responsible for what other people do to it when
bringing it up on their machines, so his S3 problems may have had nothing to
do with S3 as it came out of AT&T.
Guy Harris
Guy Harris
> >
> > (etc.)
>
> I am afraid that this is the point that proves the argument.
Bull. Absence of evidence is not evidence of absence. If you mean that the
"uptime" listing there proves that 4.2BSD systems can't stay up more than 5
days, it's time to take a course in reasoning. All it proves is that "sun"
(a machine which has had its share of hardware problems) had been up for 5
days at the time I type "uptime" at it. The last time I bounced my own
machine, it was because it hung when I tried to exit the window system -
this could have been the fault of the window system (not 4.2BSD code), the
shell I'm running (an S5R2 Bourne shell with *lots* of hacks thrown into
it), or a number of other programs whose problems you couldn't blame on
Berkeley.
> Primarily, I would like point out that five or even fifteen days of uptime
> does not make a solid operating system.
OK. Now I'll point out that frequent crashes/reboots does not make a flaky
operating system (I suspect hardware problems cause most of the trouble
around here).
> P.S. Of course, we run System V.
With, I believe, 4.1BSD memory management code (unless you've dropped the
S5R2V2 code in) and possibly 4.2BSD (or 4.1aBSD or 4.1cBSD) networking code
(the use of "ruptime" in your message gives a possible hint). As such, the
fact that CTIX stayed up on one particular machine for 45 days doesn't say
much about the reliability of System V vs. 4.xBSD.
Guy Harris
> 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
Cheryl Stewart
Is there a place where the differences between sysV and 4.2 are
documented? (please don't tell me "sure, diff the sources of both!" I'm
no sorcerer.)
ihnp4!oddjob!cs1
--
Guy Harris
> 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
Guy Harris
> > 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
Roy Smith
> 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
j...@im4u.uucp
and ditroff (after extracting it with sh). I make no claims as to its
accuracy or completeness.
(By the way, I've added "Followup-To: net.unix" to the header lines.)
: This is a shar archive. Extract with sh, not csh.
echo x - history.pic
sed -e 's/^X//' > history.pic << '!RoNnIe!RaYgUn!'
X.\" pic -Pip history.pic | ditroff -Pip
X.ps -2
X.PS
Xsmallb = 0.5i
Xmedb = 0.75i
Xbigb = 1i
Xbiggerb = 1.5i
Xboxwid = smallb
Xboxht = smallb / 2
Xmovewid = 0.5i
X
Xspacing=0.5i
Xsysv=spacing
Xmert=sysv + spacing
Xpwb=mert + spacing
Xcbunix= pwb + spacing
Xresearch=cbunix + spacing
Xv32=research + spacing
Xbsd4=research + (2 * spacing)
Xbsd2=bsd4 + spacing
X
Xboxwid = medb
XD69: box invis "1969"
XD73: box invis "1973"
Xboxwid = smallb
XD76: box invis "1976"; move
XD77: box invis "1977"; move
XD78: box invis "1978"; move
XD79: box invis "1979"; move
XD80: box invis "1980"; move
XD81: box invis "1981"; move
XD82: box invis "1982"; move
XD83: box invis "1983"; move
XD84: box invis "1984"; move
XD85: box invis "1985"
XLabel: box invis at D69
X
Xboxwid = smallb
XV1: box invis "V1" at D69 + (0, research)
XV5: box invis "V5" at D73 + (0, research)
XV6: box invis "V6" at D76 + (0, research)
Xboxwid = bigb
XV7: box "Version 7" at D78 + (0, research)
Xarrow from V1.e to V5.w
Xarrow from V5.e to V6.w
Xarrow from V6.e to V7.w
X
Xboxwid = smallb
XV32: box invis "32V" at 1/4 <D78, D79> + (0, v32)
Xboxwid = bigb
XV8: box "Version 8" at D83 + (0, v32)
Xarrow from V7.n to V32.s
Xarrow from V32.e to V8.w
Xarrow right from V8.e
X
X"\fIBell Research\fP" ljust at Label + (0, research + (v32 - research) / 2)
X
Xboxwid = smallb
XPWB: box invis "PWB" at 1/2 <V6, V7> + (0, pwb - research)
Xarrow from V6.s to PWB.nw
XU30: box invis "3.0" at 1/2 <D79, D80> + (0, pwb)
Xarrow from V32.se to 4/5 <PWB, U30>
Xarrow from V7.sw to 1/2 <PWB, U30>
XU40: box invis "4.0.1" at D81 + (0, pwb)
XU301: box invis "3.0.1" at 1/2 <U30, U40>
XU50: box invis "5.0" at D82 + (0, pwb)
XU52: box invis "5.2" at D83 + (0, pwb)
XU524: box invis "5.2.4" at D84 + (0, pwb)
Xarrow from PWB.e to U30.w
Xarrow from U30.e to U301.w
Xarrow from U301.e to U40.w
Xarrow from U40.e to U50.w
Xarrow from U50.e to U52.w
Xarrow from U52.e to U524.w
Xarrow right from U524.e
X
Xboxwid = bigb
XCBUNIX: box invis "CB UNIX" at PWB + (0, cbunix - pwb)
Xarrow from 1/4 <V6, V7> to CBUNIX.n
Xspline -> from CBUNIX.e to U301 + (0, cbunix - pwb) then to 1/2 <U301, U40>
X
X"\fIBell Columbus\fP" ljust at Label + (0, cbunix)
X
Xboxwid = medb
XMERT: box invis "MERT" at PWB + (0, mert - pwb)
Xboxwid = bigb
XUNIXRT: box invis "UNIX/RT" at D78 + (0, mert)
Xarrow from V6.s to MERT.nw
Xarrow from MERT.e to UNIXRT.w
Xarrow from UNIXRT.ne to 3/4 <PWB, U30>
X
Xboxwid = bigb
XSysIII: box "System III" at D82 + (0, sysv)
XSysV: box invis "System V" at D83 + (0, sysv)
Xoldht = boxht
Xboxht = oldht * 2
XSysV2: box "System V" "Release 2" at D84 + (0, sysv)
Xboxht = oldht * 3
XSysV24: box dotted "System V" "Release 2" "Version 4" at D85 + (0, sysv)
Xboxht = oldht
Xarrow from U301.se to SysIII.n
Xarrow from U50.se to SysV.n
Xarrow from U52.se to SysV2.n
Xarrow from U524.se to SysV24.n
X
X"\fIUSG / USDL\fP" ljust at Label + (0, sysv + (pwb - sysv)/2)
X
Xboxwid = smallb
XBSD3: box invis "3BSD" at 1/2 <D78, D79> + (0, bsd4)
Xarrow from V32.n to BSD3.s
Xboxwid = medb
XBSD40: box invis "4.0BSD" at 1/2 <D79, D80> + (0, bsd4)
XBSD41: box "4.1BSD" at 1/2 <D80, D81> + (0, bsd4)
XBSD42: box "4.2BSD" at 1/2 <D83, D84> + (0, bsd4)
XBSD41A: box invis "\s-14.1aBSD\s0" at 1/3 <BSD41, BSD42>
XBSD41C: box invis "\s-14.1cBSD\s0" at 2/3 <BSD41, BSD42>
XBSD43: box dotted "4.3BSD" at 1/2 <D84, D85> + (0, bsd4)
Xarrow from BSD3.e to BSD40.w
Xarrow from BSD40.e to BSD41.w
Xarrow from BSD41.e to BSD41A.w
Xarrow from BSD41A.e to BSD41C.w
Xarrow from BSD41C.e to BSD42.w
Xarrow from BSD42.e to BSD43.w
Xarrow right from BSD43.e
X
Xarrow from 1/5 <V32, V8> to BSD41.sw
X
Xboxwid = smallb
XBSD1: box invis "1BSD" at 1/2 <V6, V7> + (0, bsd2 - research)
XBSD2: box invis "2BSD" at V7 + (0, bsd2 - research)
Xboxwid = medb
XBSD28: box invis "2.8BSD" at D82 + (0, bsd2)
XBSD29: box invis "2.9BSD" at D83 + (0, bsd2)
Xarrow from V6.n to BSD1.s
Xarrow from BSD1.e to BSD2.w
Xarrow from BSD2.e to BSD28.w
Xarrow from BSD28.e to BSD29.w
Xarrow right from BSD29.e
X
Xarrow from BSD2.s to BSD3.n
Xarrow from BSD41.ne to BSD28.sw
Xarrow from 1/2 <BSD41A, BSD41C> to BSD29.sw
X
X"\fIBerkeley\fP" ljust at Label + (0, bsd4 + (bsd2 - bsd4)/2)
X
Xarrow from BSD41.se to 3/4 <V32, V8>
Xarrow from BSD41.s to U50.n
X
Xboxwid = medb
Xbox dashed "PDP-11" at BSD1 + (-1, 0)
Xboxwid = smallb
Xbox dashed "VAX" at 1/2 <V32, BSD3> + (-1, 0)
Xboxwid = medb
Xbox dashed "PDP-11" at PWB.w + (-1, 0)
Xboxwid = biggerb
Xbox dashed "PDP-11 / VAX" with .ne at 1/2 <U30, SysIII>
X
X.PE
X.ps +2
!RoNnIe!RaYgUn!
exit
--
John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET: j...@ut-sally.ARPA, soon to be j...@sally.UTEXAS.EDU
Tim Smith
fsck. There are problems that fsck refuses to deal with, for example,
an unallocated root inode. Fsdb is very handy in this case. Also,
possible file size errors are reported by fsck, but nothing is done with
them. Fsdb is very useful here. You can look at the inode, figure out
what the size should be ( actually, I have a program to do this part... ),
and set the size in the inode. And how about trashed superblocks?
Also, I have noticed that if an ordinary file overwrites a directory,
fsck tends to core dump on that filesystem.
--
Tim Smith
ihnp4!{wlbr!callan,cithep}!tim
Geoff Kuenning
>
>Oh sure, we can't have functions called "index" and "rindex". That's definitely
>not up to commercial standards -- we have to have them called "strchr" and
>"strrchr"... Fixing bugs is fine, but it's not usually necessary to make
>the stuff incompatible to make it work. *
"Index" is a poor name for a subroutine in the library for the same reason
that "test" is a poor name for a program in /bin. Since it's easy to handle
old programs with either the -D switch of cc or with any reasonable editor,
what's the problem? A lot of future users will be saved some nasty debugging.
The most it ever costs me is a makefile edit and a second make.
--
Geoff Kuenning
...!ihnp4!trwrb!desint!geoff
Clyde W. Hoover
>> 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.
Sorry Guy, I've got some V6 binaries that run just fine under 2.9BSD
(The sources were lost a LONG time ago).
As long as you stick to basic UNIX system calls (e.g. 'open', 'close', 'fork',
'read' and 'write'), in a '407' executable, there is no essential
system interface difference between V6 and V7 or 2.XBSD.
And except for VAX-related braindamage, I have easily gotten code
from V7/2.8/2.9 systems to compile & run under 4.1c/4.2BSD. (Suns are
another matter - much like the VAX but without some of the stranger
braindamage).
--
Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas
"Forward my mail to the corner of Pork and Beans"
cl...@ut-ngp.ARPA, cl...@ut-sally.ARPA
...!ihnp4!ut-ngp!clyde, ...!allegra!ut-ngp!clyde
John Mashey
> > > * Don't flame me if the index/strchr difference isn't an example of NIH --
> > > I haven't used V5 much...
>
> 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
John Mashey
> > 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.
Henry Spencer
> 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.
Doug Gwyn <gwyn>
> documented?
All such lists that I've seen, including internal documents of vendors,
have been quite incomplete. There really seems to be little point in
such a list, unless you're a UNIX package vendor. Only people who
specialize in this topic are likely to be able to remember most of the
differences.
The good news is, that you can develop applications under the System V
environment in such a way that they will run unmodified on any 4.2BSD
system having an appropriate compatibility package such as the BRL
emulation. (Contact your vendor for availability of some such package.)
There are a few constraints when you use this approach, but they are
much less troublesome than trying to write code to a lowest common
denominator or with enough #ifdefs to accommodate all flavors of UNIX.
Brandon Allbery
Quoted from <1...@tommif.UUCP> ["Re: instability in Berkeley versus AT&T releases"], by t...@tommif.UUCP (Tom Faulhaber)...
+---------------
| > 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00
| >
|
| machine had been up for 45 days. These machines had rebooted after PG&E
+---------------
We've shown an uptime of over 4 MONTHS (I believe it was ~ 140 days).
Microsoft Xenix 2.3a (TRS-Xenix 1.3.2) at the time. The only reason we've had
downtime is to upgrade from 1.3.2 up ultimately to 3.0.1 (Xenix 3.0), and
to format floppies since diskutil is, regrettably, standalone.
I post this not to show off, but to note that an uptime war between AT&T and
BSD is just a bit ridiculous. I thought unix-wizards were more mature than
that. (Or did this cross over from net.unix? If so, send it back!)
--bsa
--
Brandon Allbery, Unix Consultant -- 6504 Chestnut Road, Independence, OH 44131
decvax!cwruecmp!ncoast!bsa; ncoast!b...@case.csnet; +1 216 524 1416; 74106,1032
========================> Trekkies have Warped minds. <=======================
Stanley Friesen
>
>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...
>
Holy Cow! Is this really true! How revolting. I think you
could retrieve a backed-up file by name even back in V7 days!
Now my two cents worth on the general subject. We have almost
never run into significant software related problems here, and we have
been running vanill BSD 4.x for about 2 years. The closest we came was
a flaky interaction between Massbus 2 and Massbus 0 which resulted in
a hung tape drive periodically. Our vendor fixed this almost immediately.
Other than this we have only had hardware problems - the perennial
tbuf parity fault bit(which I think System V is also subject to),
and the usual power failures and so on. seems like a stable system to
me.
--
Sarima (Stanley Friesen)
{trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen
or {ttdica|quad1|bellcore|scgvaxd}!psivax!friesen
Ron Heiby
>Hostile users aren't the only good reason to have quotas. What about
>buggy software that gets into an infinite loop writing to a file?
That's what "ulimit" is for. Don't use an SST when roller skates will do.
--
Ron Heiby he...@cuae2.UUCP (via ihnp4)
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
Peter DaSilva
>
> 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.
Venix comes with virtually all the utilities & runs on a PC-XT. That's a 10
megabyte disk, folks. Not an Eagle. That's not a reason, that's not even an
excuse, that's just a rationalisation.
Peter DaSilva
> >
> > (etc.)
>
> I am afraid that this is the point that proves the argument. We have
> an Ethernet composed of Convergent MiniFrames (the parent of the PC 7300)
> in Un*x engineering at CT. A few days ago an ruptime display would have
> shown you that the Networking development machine (mine) and the OS development
> machine had been up for 45 days. These machines had rebooted after PG&E
> decided to run over one of the power lines to our building. Unfortunately last
> week they ran over the power lines again! I would note that the OS
> development machine was running the latest CTIX version, and the networking
> machine was running an experimental kernel.
>
> I say this only partially to brag about our systems. Primarily, I would like
> point out that five or even fifteen days of uptime does not make a solid
> operating system.
>
> Tom Faulhaber
We have an old LSI-11 running V7. Uptime is 49 days. I don't recall the
last time it went down but I think it was because of a power failure. Before
that the last reboot was in March when we replaced the flakey hard drive.
I have no intention of ever getting a SV system if I can at all avoid it. I
have too much software that Bell won't run because they used PWB as the basis
for SIII instead of V7 (the last true UNIX). 4.2 is exceptionally compatible
with V7... and the 4.2 system next door has proven itself reliable.
Peter DaSilva
> advantage of System V (notice that "UNIX" is omitted here)
> with regard to stability is that all significant commercial
> UNIX and C standardization efforts are adhering closely to it
> (and vice-versa).
It is to laugh. Most real world UNIX systems are STILL descendents of V7.
Peter DaSilva
> out of being a much talked about OS into being a much used OS.
I'd love to join a UNIX users group which doesn't have outrageous membership
fees. Next question: who is going to implement it?
Peter DaSilva
> [Guy Harris]
[ME]
> > 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 never said it wasn't. The V7 was an early 2BSD release. The V6 was vanilla
V6 (the Berkeley comp center is terribly conservative. They still had one
machine running V5!).
> (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.
I have run V6 binaries on V7. I was at berkeley when the V6/V7 switch was
going on and this was the only way to get certain traditional programs for
V7. We were also running an RSX (!) version of basic+, suitably patched.
Source for V6 ran on V7 with very few problems (had to change RAW to CBREAK,
that was about all).
> And there are programs written for V7 that will break when you try to
> compile them and run them under 4.2BSD...
Yes, but it's a hell of a lot easier to fix them for 4.2 than for
> > 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 V7 and derivatives is the most common UNIX in the real world...
> Guy Harris
Peter da Silva
Peter DaSilva
> [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?
HopkinsWE
yes, stty is no longer included in official System V Release 2 documentation,
but it is still there in the kernal (it calls ioctl). I ran into it
while modifying some code, didn't find it in 5.2, 5.0, or 3.0 manual,
then asked someone who had 4.2bsd background who recognized it and
then tracked it down in the kernal.
Bill Hopkins
AT&T Information Systems
ihnp4!druny!weh
Griff Smith
> >Hostile users aren't the only good reason to have quotas. What about
> >buggy software that gets into an infinite loop writing to a file?
>
> That's what "ulimit" is for. Don't use an SST when roller skates will do.
If you haven't worked where people use UNIX systems to do real data
processing, don't propose "ulimit" as an alternative to quotas. A 50
meg file won't even cause a batted eyelash here. When you lose half a
day because you forgot to cast the proper spell to bypass a per-file
size limit, per-file-system limits look much more attractive. The BSD
quota system also supplies detailed, quickly-accessible, reports of
disk usage. I don't have time to use combinations of "find" and "du"
when the console is screaming "disk full". We set our quotas very high,
but they are convenient fire walls. The first thing we do to "ulimit"
is to set it to a huge value; the time lost due to hitting the standard
value is just not worth it.
--
Griff Smith AT&T Bell Laboratories, Murray Hill
Phone: (201) 582-7736
Internet: g...@ulysses.uucp
UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
J. Shapiro
> > Henry Spencer @ U of Toronto Zoology
>
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
Chuck Hedrick
Control, I have little sympathy. It is crazy to think that quotas are
going to let you decrease a user's disk usage below what he seriously
believes he needs. But in a cooperative environment, they provide a
convenient benchmark, that documents what the user has agreed to. The
4.2 quota system is particularly nice, since it forgives a few
overages, and allows for more working space when logged in. They
cause people to look at their file usage a bit more than they would
otherwise, and to think for 30 seconds whether they really want to ask
me for more space. That's useful, and about all one should expect.
Doug Gwyn <gwyn>
Must be an alternate universe (see net.physics).
Joel West
> However, this is misleading. In the first place, dungeon is really an RSX-11
> binary (from a Fortran source) which was munged into a V6 binary which was
> in turn munged into a V7 binary (the differences between V6 and V7 binaries
> really aren't that great), and chess is really a V7 binary.
>
> In the second place, what's really happening here is that these binaries are
> PDP-11 binaries (that's what V6 and V7 ran on) which are run in VAX
> compatibility mode (the VAX hardware supports such a thing) using a program
> called /usr/games/lib/compat and a front end to open the files.
Oh, oh. I'm no longer looking forward to getting my MicroVAX II (which
I think has dumped PDP-11 once and for all). I won't be able to play zork!
:-( [:-)]
Joel West CACI, Inc. - Federal (c/o UC San Diego)
{ucbvax,decvax,ihnp4}!sdcsvax!jww
j...@SDCSVAX.ARPA
Henry Spencer
> 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
Roy Smith
What started out as (yet another) discussion about 4.2 vs. Sys5 has
now turned to discussing disk quota systems. Since I would hate to see
mod.unix die out, I have taken advantage of this change of topic and sent a
followup article to mod.unix; see you all there.
Eric Carroll
>
> 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
J.WOOD
Mash:
While we're arguing about who's the biggest pack rat,
my PWB UNIX Usser's Manual Edition 1.
It has neither strcatn nor strncat nor index in strings(III),
but it does have an original "Programmer's Workbench
Documentation Roadmap," Author J. R. Mashey, 01/18/77 :-)
Joseph L. Wood, III
AT&T Information Systems
Laboratories, Holmdel
(201) 834-3759
<ariel!>titania!jlw
Guy Harris
> is misleading.
Certainly is. 4.2BSD can run PDP-11 V6 binaries (there are other V6
binaries), but V7 can't. ("stat" changed radically, and unlike the
V7/4.2BSD change to "stat" it isn't source-compatible or binary-compatible.
"seek" got replaced by "lseek".) 4.2 can do it because the
compatibility-mode emulator simulates the system calls, and can simulate V6
calls as well as V7 ones.
> not on a Sun or other 4.2BSD machine (where you won't find zork or chess.)
For what it's worth, my Sun UNIX 2.0 manual has a section CHESS(6) -
somebody here rewrote the assembler-language part of "chess" in 68000
assembler language.
> Nonetheless, most V7 programs will compile and run happily on 4BSD, which
> is not true of System V.
Depends on how you define "most". V7 programs which assume "read"s and
"write"s on slow devices return EINTR when a signal breaks through them
don't run happily on 4.2BSD. S5 programs that don't use any library
routines not in V7 (other than "strchr"/"strrchr") and don't do terminal
"ioctl"s will (modulo a couple of exceptions, I suspect) compile and run
happily on V7, 4.1BSD, 4.2BSD, ... (S5 programs that *do* use library
routines not in V7 won't work, but then 4.2BSD programs which use library
routines not in V7 won't work on V7 or S5 either.)
Guy Harris
Guy Harris
> >Hostile users aren't the only good reason to have quotas. What about
> >buggy software that gets into an infinite loop writing to a file?
>
> That's what "ulimit" is for. Don't use an SST when roller skates will do.
*ONLY* if the default "ulimit" is infinity, not the dumb 1MB that comes with
S3/S5 out of the box from AT&T. Put a "ulimit" on programs you want to
debug (note that an almost-identical facility, except for a signal SIGXFSZ
which is delivered to the errant program, exists in 4.xBSD). DON'T penalize
database systems which want to maintain big databases (and don't force me to
run those systems as root just to boost their "ulimit"), or other programs
which, for whatever reason, need files bigger than 1MB.
Guy Harris
Curtis Jackson
>
>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.
The only thing terrible about 'ls -C' is that 'ls -CF' ought to be the default
for CRTs. Your option (ls -C as default) would _require_ the "-F" to get
the directory/executable_file markings, which _is_ brain damaged.
In short, everyone likes something different; therefore the word 'option'
is quite often used in Unix documentation. If you don't like it, get
a reasonable shell so you can alias 'l' to be 'ls -CF', 'ls -C', or
whatever you like.
Remember, folks, this is "Unix", tm, registered, summa cum laude, etc.;
remember the flexibility that stands for? Remember the amazement of
the IBM JCL jockey when he bitched about the Unix 'cat' command and you
shrugged and said, "Write your own and call it cat."?
Unix is what you make it (thank God, Kernighan, Thompson, et. al.),
--
The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj
...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj
Geoff Kuenning
>
>If you haven't worked where people use UNIX systems to do real data
>processing, don't propose "ulimit" as an alternative to quotas. A 50
>meg file won't even cause a batted eyelash here. When you lose half a
>day because you forgot to cast the proper spell to bypass a per-file
>...We set our quotas very high,
>but they are convenient fire walls.
Sounds to me like quotas aren't really what you want, either. You don't
want to set artificial limits on people's work (and any limit, no matter how
high, is going to be a problem for someone someday). What you really want
is an OS that doesn't make it nearly impossible to deal with exceptional
conditions. UNIX's response to a filled disk comes from the "panic: out
of swap space" days when nobody really wanted to write the tough code because
it wasn't that important. If Berkeley (or AT&T) would put as much effort into
the disk-full problem as was put into "swkill()" in 4.2, I bet you'd happily
stop using quotas.
--
Geoff Kuenning
...!ihnp4!trwrb!desint!geoff
Doug Gwyn <gwyn>
> S3/S5 out of the box from AT&T.
Yes, AT&T, please change this. A 1Mb default ulimit is unnecessary;
the system manager could set this up in /etc/profile (like umask) if
he thinks it is needed.
Doug Gwyn <gwyn>
> 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.
David Herron, NPR Lover
>> file it's a lot nicer than "od -c". And what's so terrible about "ls -C"?
>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.
er .... read the earlier book "Software Tools".
They talk all about the "One program, one function, done well" philosophy.
It's very good. Very nice. Very reasonable. I go along with it completely.
But they say one other thing. "When you have functions which are commonly
done together then why not put them into one program."
For instance. sort(1) didn't always do the function of uniq. But now
it does because they were commonly done together.
But ... you have to judge each case carefully.
In the case of cat -v, it really does produce more readable output. At
least for some cases. But it's output isn't very usable (You can't convert
it back into the input file for instance). With od -c you COULD write
a program to convert the output back into the input. It really depends
what you are wanting to do with the output.
In the case of ls -C, you have some qualitative gains. ls -C is able to
optimise the formatting. And it IS a lot more useful than having
to type the ls | mc string.
On the other hand, it's signs of "creeping featurism", a particularly
nasty form of cancer which spawns such monstrosities as EMACS and VMS
and the like.
HACKERS OF THE WORLD UNITE!
YOU HAVE NOTHING TO LOSE BUT YOUR MLISP!
:-)
--
--- David Herron
--- ARPA-> ukma!da...@ANL-MCS.ARPA
--- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david
--- {ihnp4,decvax,ucbvax}!cbosgd!ukma!david
Robert Elz
>
> Nobody is arguing that the functionality isn't useful; it's just misplaced.
>
> way to build a system, see almost any discussion of the "Unix philosophy".
The problem is, that its very hard to define the "one function" in any
way that's acceptable to more than a handful of people.
For listing a directory, my idea of "one function" would be to
simply read the directory and print the names. no more. no
sorting, no looking up attributes (stat calls), none of this
unnecessary crud. In fact, "ls" can do this, but you have to
tell it "-f".
The real point is, of course, that by the time that you
run a sh script like
ls | sort | mtimes | sizes | owner | links | permissions
every time you want what you would normally get with "ls -l"
the whole system will die. (This asumes that each of the named
commands reads stdin, extracts the file name (last word on each line)
and prepends its info to the start of the line, to make a listing
that looks just like "ls -l" does now. Of course, it would be nearly
impossible to do things just this way, but you get the idea. And
imagine the flexibility, if you want reversed sort by size, just do
ls | mtimes | sizes | nort -nr | owner | links | permissions
Try doing that with a "standard" ls!). Really, even this is wrong,
none of these tools should worry about making the output line up in columns,
really what should happen is the output fields should be separated
by tabs, so to make a neat looking "ls -l" you would do..
ls | sort | mtimes | sizes | owner | links | permissions | \
cat ls.tbl.hdr - ls.tbl.trailer | tbl | nroff
I'm sure that I am still embedding some functionality here in the
wrong program, I leave it for others to correct me.
But, others might define the "one function" of a directory listing
program as producing all the information that you might want about
about the files in a directory, with options to control exactly
what information is presented, and in what form.
With such a definition, sorting (with a myriad of options
to define just what is the sort key) and columnising make
equal amounts of sense. Even if you object to the "what form"
part of the definition, surely sorting & columnising stand or
fall together?
The real problem, is that there are people who imagine that
the "one function" that a program is supposed to solve is
the "one" that it originally solved, and that any change,
either to delete "wrong" functionality, or add "new" functionality
is automatically a "bad thing". (This is quite apart from the
problem of incompatible versions, which really is a problem).
Had "ls" output file names in columns from its first writing
with an option to produce only 1 column when its output is
being piped into some other program, then there would be none
of this controversy. (I know, people scream "but programs
should always be written to assume that their output will
be the input of another program")
What's really hard to justify is having the output appear
in a different form depending on where the output is going,
but such is the price of backward compatability - and we
*know* who it is that screams loudest whenever something
is changed that "breaks" something, don't we?
Robert Elz ucbvax!kre k...@monet.berkeley.edu
ps: K&P on this topic suggest using "pr" as a columnising filter.
To my mind, "pr" is a paginator, its just as bad to make a paginator
produce columns as some side effect as it is to make a directory
listing program produce columns as a side effect - but of course,
this was in "pr" from the beginning, so it is blessed...
Tim Smith
--
Tim Smith
ihnp4!{wlbr!callan,cithep}!tim
Don Speck
Cit-vax is our general-use machine, with undergraduate classes,
grad students, and professors. It used to have disk quotas, but
when I was made system manager, I turned them off. Why? I noticed
that quota policy was primarily directed against class accounts,
which didn't stick around long enough to accumulate much in the
way of files; meanwhile, those in most need of restraint (the long-
time users of the machine) had infinite or extremely large quotas,
and disk usage to match. The disks were always full.
I turned off quotas because they were not serving to keep the
disk from running out of space, rather, they were serving to enforce
class distinctions. Of course, my decision may have been colored by
having been at the low end of this class structure before becoming
system manager... and my inability to say "no".
Don Speck sp...@cit-vax.arpa
Father of micro-S
>> 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.
So make ls check the width of the window, and do multi-column if possible
according to the width of the window.
-----------------------------------------
Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027
ARPA: ukma!sambo<@ANL-MCS>, or sambo%ukma...@anl-mcs.arpa,
or even anlams!ukma!sa...@ucbvax.arpa
UUCP: {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!sambo,
or cbosgd!ukma!sambo
"Micro-S is great, if only people would start using it."
Rich A. Hammond
I (very infrequently) want to do something like "ls|tee foo" and I always
get bitten by the Berkeley bug that ls then does a different thing.
With the csh and aliases, ls shouldn't bother trying to be smart, let
the user alias l to ls -CF or whatever she wants.
As for the comment about pr doing multi-column output being undesirable,
since pr is a paginator, think about it for a minute and explain how
you would take a single column file and make it into multiple columns
such that the second column on the first page started with the line
that follows the last one on the first column without knowing how long
the page was? Since the columnizing program also has to know the page
length and width, I see some justification for it all being in one program.
Rich Hammond
ha...@siemens.uucp
> > 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
ha...@siemens.uucp
> > Nobody is arguing that the functionality isn't useful; it's just misplaced.
> >
> > 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".
>
> The problem is, that its very hard to define the "one function" in any
> way that's acceptable to more than a handful of people.
>
> For listing a directory, my idea of "one function" would be to
> simply read the directory and print the names. no more. no
> sorting, no looking up attributes (stat calls), none of this
> unnecessary crud. In fact, "ls" can do this, but you have to
> tell it "-f".
>
> The real point is, of course, that by the time that you
> run a sh script like
>
> ls | sort | mtimes | sizes | owner | links | permissions
>
> every time you want what you would normally get with "ls -l"
> the whole system will die.
Yes. But, aside from the fact that ls had the -l option, what makes
ls -l anything but another example of creeping featurism. Berkeley ls
just takes a bad trend and makes it worse. I want my ls command to be
what 4.2 and sysV call ls -1f. This is useful to pipe to programs.
For a user interfaced version (maybe lsc) i would set a sh script or
alias of ls | grep -v '^\.' | sort | columnate. If I find that this is
terribly slow, then maybe incorporate the checking for files beginning
with '.' into ls and provide a '-a' option, maybe even '-A' (same as
'-a' but without files '.' and '..') or maybe make it an option to trim
those files. Next, if sorting is that important and the extra exec and
pipe I/O is a real slowdown, then add an option to for sorting, or even
make that the default.
ls -l is really a separate case. It provides completely different
information. Why not have one program which takes a list of named
files and produces ls -l style output. Default might be the same as
ls or might be something else, and it might handle named directories
differently (ls -ld always seemed awkward to me, why not ls -l name and
ls -l name/*). I personally think of ls -l as a very different program
from vanilla ls, and consider the bundling of the two a design problem.
Maybe I'm alone in this.
You suggest that the function that ls provide could be done as separate
filters. Why not just provide wc like command line options for which
fields you want (lsl -is for inode number and size) and make the default
all. Simple to implement. Separate function from other programs
(program to return data from inode rather than list files in a directory).
Easy to understand what it does (no -[a-zA-Z]). However, for the sake of
compatibility, things probably shouldn't be changed. But ls -l isn't
a good example of anything.
> ... surely sorting & columnising stand or
> fall together?
No more so than sorting and removing files that start with '.' are linked
or listing files and printing stat information on files are inseparably
bound.
> The real problem, is that there are people who imagine that
> the "one function" that a program is supposed to solve is
> the "one" that it originally solved, and that any change,
> either to delete "wrong" functionality, or add "new" functionality
> is automatically a "bad thing". ...
It's just that the original design in Unix is, on average, good. Not
to say that everything is the best it could possibly be, just not bad.
> ... (This is quite apart from the
> problem of incompatible versions, which really is a problem).
Yes. No question there.
> Had "ls" output file names in columns from its first writing
> with an option to produce only 1 column when its output is
> being piped into some other program, then there would be none
> of this controversy. (I know, people scream "but programs
> should always be written to assume that their output will
> be the input of another program")
Maybe, but I'm not sure that it would have.
> What's really hard to justify is having the output appear
> in a different form depending on where the output is going,
> but such is the price of backward compatability - and we
> *know* who it is that screams loudest whenever something
> is changed that "breaks" something, don't we?
Agreed. But kludging things to be backward compatible in special cases
is definitely not the right way to add features.
> Robert Elz ucbvax!kre k...@monet.berkeley.edu
> ps: K&P on this topic suggest using "pr" as a columnising filter.
> To my mind, "pr" is a paginator, its just as bad to make a paginator
> produce columns as some side effect as it is to make a directory
> listing program produce columns as a side effect - but of course,
> this was in "pr" from the beginning, so it is blessed...
It seems to me that a program for paginating might have to worry about
columns, but, yes this is probably not the best place to put a columnator.
On the other hand, it is possible to use the columnator from pr from other
programs, where with ls it's at very least kind of difficult (create a file
with the name of each line, do a ls -Cf, and hope that there aren't two
files with the same name? :-)
--
Paul Haahr
..!allegra!princeton!haahr
Ron Heiby
cross-posted with net.unix-wizards (trash dump). Really, I'm very
sorry that I started a religious battle (or two or three) on V7 vs.
4BSD vs. SysV vs. ..... P-leeeeease read what I say and assume that
I mean it if I don't use a smiley face.
I made a remark about the different orientation of a research /
teaching organization vs. a commercial computer vendor and suddenly
I was accused of bad-mouthing products that had adapted software
developed by the research / teaching organization. I made a remark
that ulimit could be used in direct response to someone who asked
about how to control / test "buggy software". I did NOT recommend
that a small ulimit be used for database applications, nor did I
recommend that it be a low value by default in all cases, nor did I
suggest that it was a panacea that eliminated the need for other
disk usage tracking and control tools. Good grief!
Can we drop all this now and get on to something worthwhile? Or
maybe we can at least leave the religious debates in
net.unix-wizards and obviate the need for a mod.micro.att.
--
Ron Heiby he...@cuae2.UUCP (via ihnp4)
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
x0705
Actually, the SVR2 ls -C looks at the COLUMNS variable to find out how much
space is available, and adjusts the number of columns accordingly.
The 4.1BSD ls checked whether isatty(stdout), and set the output to single or
multi-column accordingly; I always hated that since I normally wanted
multi-column all the time.
--
## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
Peter DaSilva
>
> Must be an alternate universe (see net.physics).
Replace "real world" by "outside AT&T". WHat AT&T does internally on their
3B20Ds is pretty much irrelevent to what I want to do on my PDP-11. IBM is
pretty braindamaged but even they don't require you to run MVS on your XT. AT&T
was quite happy with having an external and an internal system before System
III.
Also most "non AT&T" UNIX systems predate System V. The ones that claim to be
System III are almost all Microsoft or Unisoft releases and are V7 with
SIII patches (which is why I didn't have to know about MIN & TIME when I was
working on Xenix 3.0. Nice of Microsoft to tell me).
Peter DaSilva
> yes, stty is no longer included in official System V Release 2 documentation,
> but it is still there in the kernal (it calls ioctl).
If it's there it should be documented or porters will eat it. What are the
parameters & structures this version accepts? V6 or V7?
Peter DaSilva
> > is misleading.
>
> Certainly is. 4.2BSD can run PDP-11 V6 binaries (there are other V6
> binaries), but V7 can't. ("stat" changed radically, and unlike the
> V7/4.2BSD change to "stat" it isn't source-compatible or binary-compatible.
> "seek" got replaced by "lseek".) 4.2 can do it because the
> compatibility-mode emulator simulates the system calls, and can simulate V6
> calls as well as V7 ones.
Fine, as long as it doesn't use stat, sgtty, or lseek it's OK. How many
programs use stat, sgtty, or lseek? Mainly system programs, which will
come with the new system.
Peter DaSilva
I type "ls" all the time. I like columnar output. I'm running on an LSI-11 in
which the script is significantly slower than the command.
We don't all have vaxes.
Peter DaSilva
> a reasonable shell so you can alias 'l' to be 'ls -CF', 'ls -C', or
> whatever you like.
OK. The ls we have here, ported from 4.2, munged by tek, has the following
links:
l ls -m
ls ls -C
lf ls -CF
ll ls -l
Not everyone can get a reasonable shell. You want to mail me a copy of a
korn shell binary for a vanilla PDP-11 V7 system? Or CSH? Or even the source?
I don't have a UNIX source license. Or a reconfiguration license. or a SV
license. Then I'll give you your point.
Peter DaSilva
> 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?
Guy Harris
> 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
J. Shapiro
I was waiting for someone to say that. I knew the net could be relied on for
a straight line. Consider that generating multiple columns requires a know-
ledge of terminal width, and that I did not insist that "ls" be stupid. I
If my window is wide enough for two columns, that is how I want my display.
There is a difference between being "crufty" and paying attention to detail
and niceities that make life easier on a user. Whether -C should be the
option or -1 should be the option should not be determined by your or my
blathering. It should be determined by what the bulk of the users
want, modified by what is feasible, reasonable, and sensible.
Part of the pleasure of dealing with UNIX, to me, is the fact that
utility programs don't insist on being unduly stupid. As to my model
being overly restrictive, that is simply untrue, as I hope is now
clear. Utilities ought to behave reasonably, and this in no way
detracts from the robustness of my model - she's terrific;-)
Jon Shapiro
Haverford COllege
Robert Elz
> If Berkeley (or AT&T) would put as much effort into
> the disk-full problem as was put into "swkill()" in 4.2, I bet you'd happily
> stop using quotas.
I would love to somehow handle full disk conditions gracefully,
but can you suggest how?
Swap errors (swkill stuff) is easy - kill the process with the problem.
If the system had paniced the process would be killed anyway, so its
no worse off, and the rest of the processes are considerably better
off for not panicing.
But how do I handle a full disk? Killing some random process won't
fix it (not even killing ones writing to the full filesys).
I could just delete some random files - but somehow I suspect their
owners might get upset.
So, does anyone have any good suggestions on how to sensibly handle
full discs? The problem is really one of user control - only users
know which of the allocated blocks on the disk contain useful information,
and which contain trash.
This seems to be a situation where avoiding the problem (by simply
plugging in another eagle every week for preference, disk quotas
if that answer isn't viable) is the only reasonable action.
Robert Elz ucbvax!kre
Bruce Robertson
It is V6, unfortunately. I was very disappointed when I found this out, and
promptly upgraded it to V7.
--
Bruce Robertson
UUCP: {ucbvax!menlo70,seismo}!unr70!unrvax!stride!bruce
Sean Casey
and loops while writing to a file. The SA comes in in the morning and finds
30 feet of console output complaining about a full disk.
For example:
shar -bcv * > sharfile
Something this innocent looking can do it.
--
- Sean Casey UUCP: se...@ukma.UUCP or
- Department of Mathematics {cbosgd,anlams,hasmed}!ukma!sean
- University of Kentucky ARPA: ukma!se...@ANL-MCS.ARPA
Guy Harris
> 4.2BSD!).
Well, let me amend that to "S3 binaries"; S5 COFF binaries can't be executed
by vanilla 4.2BSD, although the changes required are (relatively) localized
(unless you want to execute demand-paged binaries from S5R2V2, in which case
the fact that S5R2V2 is basically modeling a segmented/paged MMU on the VAX
hardware, and as such wants to put segments on 64KB boundaries, will bite
you - you can still do it, but it reaches the point of diminishing
returns...)
Guy Harris
John Mashey
> > > 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.
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.
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?
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
Guy Harris
> your XT.
That's a remarkably irrelevant example, considering 1) it has nothing to do
with internal vs. external releases and 2) since MVS is written in 360
assembler and PL/S, and since the former *can't* run on an 8088 without a
slow simulator and the latter probably has lots of 360-dependent goo in it,
you couldn't run MVS on a PC anyway.
> AT&T was quite happy with having an external and an internal system before
> System III.
I see no reason to assume they were happy about it. Remember a little
something called the "Consent Decree"? AT&T *wasn't allowed* to be in the
computer business *at all* before the breakup - there were suits from ADAPSO
trying to get UNIX off the market!
> Also most "non AT&T" UNIX systems predate System V. The ones that claim to
> be System III are almost all Microsoft or Unisoft releases
The HP ones? The CCI one? (more on that one later) The Plexus one?
> and are V7 with SIII patches
So what? The TTY driver seems to be your primary source of dyspepsia; I
suspect most systems which are "V7 with S3 patches" have S3 libraries and a
kernel which started out as a V7 kernel and got changed to resemble S3,
including having the S3 tty driver dropped into it (I know that's how the
CCI system was done, since I was one of the people who did it). As such,
well, if it looks like a duck, and walks like a duck, and quacks like a
duck, who cares if it's a goose with duck patches?
> (which is why I didn't have to know about MIN & TIME when I was working
> on Xenix 3.0. Nice of Microsoft to tell me).
This has been explained to you elsewhere, but if you're clearing the ICANON
bit, you either have to set MIN and TIME to get reliable results or they
botched the tty driver.
Guy Harris
John Mashey
> 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.
Guy Harris
Why not have a command called "vis" (as I believe P of K&P
has suggested) which does the job of "cat -v"? Nobody's
arguing that there's no need for a program to send files
to the terminal (or elsewhere) with control characters
escaped. "cat" isn't the "official" file-typing program
on UNIX; its official role is to concatenate several files
and send the result to the standard output. (That's why
the seemingly-strange name which people who want to poke
fun at UNIX pick on.) A consequence of this is that it can
be used to type files. Most of the time *I* use "more",
not "cat", to type files, because I 1) don't like data
scrolling off my screen and 2) don't like the "built-in" pager
that the window system here has.
It's somewhat a question of whether adding the extra functionality
to "cat" 1) slows "cat" down (which it *will* do if the same
path is used for "cat -v" and "cat", since the former must
inspect each character as it goes by and the latter need not),
2) makes "cat" into two independent programs with a small bit
of connective tissue holding them together (which it will do if
different paths are used for "cat" and "cat -v", or 3) makes
the system conceptually more complex by bundling two (or more)
distinct functions into one program.
Why "ls | pr" isn't good enough, but why "ls -C" might not be the best
solution:
I *VERY* frequently do things like
ls *
when the current directory is full of directories. When
used with the Berkeley "ls" (or the S5R2 "ls" with the "-C"
flag), this gives me an extremely attractive and easy to read
listing of the form:
directory1:
file1 file2 file3
directory2:
file1 file3 file5 file6 file7 file8
file2 file4
"ls | pr", or "ls | any_other_general_filter", can't do this
because it doesn't know that its input is coming from "ls"
(that's because it *is* a general filter) and can't tell
the difference between directory name headers and file names.
A filter to decipher the output of a single-column "ls" (including
recognizing the difference between a heading like "directory1:"
and a file whose name ends with colon - this may sound trivial
but not doing this correctly is just sloppy) and put it into
this format would be very nice - and probably useless for
anything other than piping "ls" into. *I* refuse to accept
any multi-column-listing solution which can't produce that
kind of output for "ls <-C> *", no matter how conceptually
correct it is.
However,
ls -C /usr/src/cmd/*.c
doesn't really do the optimal thing, either. On a DEC or
other system where file-name expansion is done in the program,
rather than in the shell, the program would know enough to say:
/usr/src/cmd:
bar.c bletch.c frotz.c mumble.c quux.c
baz.c foo.c
which is the ideal format for human consumption. Both Berkeley's
and the USDL's "ls" will, instead, do
/usr/src/cmd/bar.c /usr/src/cmd/frotz.c
/usr/src/cmd/baz.c /usr/src/cmd/mumble.c
/usr/src/cmd/bletch.c /usr/src/cmd/quux.c
/usr/src/cmd/foo.c
which contains a lot of redundant information and requires more
columns because of that.
The ideal would be a filter which did this correctly. However,
I don't have time nor much inclination to write it.
Moral: religious questions, like other questions, don't always have simple
answers.
Guy Harris
pre...@ccvaxa.uucp
> > ps: K&P on this topic suggest using "pr" as a columnising filter.
> > To my mind, "pr" is a paginator, its just as bad to make a paginator
> > produce columns as some side effect as it is to make a directory
> > listing program produce columns as a side effect - but of course,
> > this was in "pr" from the beginning, so it is blessed...
> It seems to me that a program for paginating might have to worry about
> columns, but, yes this is probably not the best place to put a
> columnator. On the other hand, it is possible to use the columnator
> from pr from other programs, where with ls it's at very least kind of
> difficult (create a file with the name of each line, do a ls -Cf, and
> hope that there aren't two files with the same name? :-)
----------
How can you separate columnising from paginating? Clearly you can't
columnise first, then page (you'd like the right column of a page
to follow from the left column, not from the bottom of the left
column of the last page). Nor can you page first, then columnise.
You need a global process that alternates between grabbing enough
material for one page and formatting it for display. That requires
either a more complicated shell than Unix has or that the processes
be turned into one program. It might be possible to embed the
global knowledge in a shell script, but it would be a real pain.
I think this is an example of something that is best done as a
program.
I tend to agree that ls should NOT do columnising for this same reason.
Its columnising is wrong for pagination (it has to assume an
infinite page length).
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
Peter DaSilva
> the work of figuring out the (admittedly complex) interface...
First I had to FIND the interface. That's exactly my complaint. It's complex.
It's also well hidden (what in the hell is it doing in the administrator's
manual?????).
> (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...)
This is a problem, though non-interrupting signals are nice they should have
implemented it only in the new signal stack, leaving the old signals alone.
4.2 has 2 counts against it (signals and directories). SV has more than that.
> > > ...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.
Well, they should have made 2.0 compatible with V7 when it became obvious that
V7 was succeeding outside Bell, but... c) keep the V6 system call emulation
or change it to V7 emulation. Either would do.
> As for your claim that "most real world UNICES are V7 derived", I don't
> believe it. Period.
Most real world UNICEs were installed before the SV interface definition came
out. But examples: UniPlus+ SIII is actually V7 with some SIII additions. So
is Xenix 3.0. The TRS80 Model 16 is an extremely common UNIX box. It's V7.
> Most commercial vendors are offering S3 or S5-based
> systems.
Most SIII systems are actually V7 plus SCCS, as noted above. This is why I
thought SIII was V7 compatible: all teh SIII systems I had used were actually
V7.
> 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?
You first.
Peter DaSilva
> 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.
A VAX 750 is a bit of a powerhouse even today. On small machines that amount
of efficiency isn't trivial.
Peter DaSilva
> filters. Why not just provide wc like command line options for which
> fields you want (lsl -is for inode number and size) and make the default
> all. Simple to implement.
I implemented this. Called it "le" for "list extended". It dumps all sorts of
extra info too. Found I don't bother to use it. Anyone want a copy?
Peter DaSilva
> >> yes, stty is no longer included in official System V Release 2
> >> documentation, but it is still there in the kernal (it calls ioctl).
> >
> >If it's there it should be documented or porters will eat it. What are the
> >parameters & structures this version accepts? V6 or V7?
>
> It is V6, unfortunately. I was very disappointed when I found this out, and
> promptly upgraded it to V7.
Well if they'd document this & make sure it doesn't go away I'd drop any
possible objection to the current ioctl. It's a lot more powerful, but for
simple stuff (like setting rawmode) it's too complex.
Doug Gwyn <gwyn>
> > > 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.
>
> space is available, and adjusts the number of columns accordingly.
> The 4.1BSD ls checked whether isatty(stdout), and set the output to single or
> multi-column accordingly; I always hated that since I normally wanted
> multi-column all the time.
Columnators should also do an ioctl(TIOCGWINSZ) or the DMD equivalent.
Our "mpx" does not alter the COLUMNS environment variable for each
layer, but rather stores the window size in the tty structure.
Actually, if you want columnated "ls", given the way "ls" works it
is necessary to either build the columnation into "ls" or to provide
a very specific columnizing filter, since "ls" lists multiple
directories WITH HEADERS so that simple-minded columnizing will mess
up the output. I think the SVR2 method (requiring an explicit request
for columnation) is preferable to Berkeley's automatic behavior. It is
very easy to make up a shell function, alias, or script like
l(){
ls -Cf $*;
}
to make your own personalized "l" command if you want one.
Default command behavior should be simple, with complexities reserved
for the options.
P.S. I think I started the "ls" debate, but all I said was that I
thought "ls -[a-z][A-Z]" was yucky (too many options to remember).
I don't like a directory-entry listing utility having to know about
terminal characteristics, though. This seems like an unnecessary
combining of function. I like Peter Weinberger's idea of having a
directory format that is directly printable:
10038 .
10039 ..
10502 myfile
10501 mydir
etc. It would even be nice to get rid of . and .. I guess it's too late...
Tim Smith
>> 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
>
Ever used a windowing system in a bit mapped display? HE will be part of
the majority, not you.
>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?
Excuse me, but it is not AT&T that is putting in special cases! And why is
accounting a special case? You are perfectly free to turn off and remove all
accounting stuff from your 7300 ( This is complete speculation on my part,
but they couldn't have shpxrq(ROT 13) it up THAT badly, could they? )
--
Multi-column output should be handled in the terminal driver, so
all program will be able to use it. :-)
Tim Smith
ihnp4!{wlbr!callan,cithep}!tim
Ed Nather
>
> ls -C /usr/src/cmd/*.c
>
> doesn't really do the optimal thing, either. On a DEC or
> other system where file-name expansion is done in the program,
> rather than in the shell, the program would know enough to say:
>
> /usr/src/cmd:
> bar.c bletch.c frotz.c mumble.c quux.c
> baz.c foo.c
>
> which is the ideal format for human consumption. Both Berkeley's
> and the USDL's "ls" will, instead, do
>
> /usr/src/cmd/bar.c /usr/src/cmd/frotz.c
> /usr/src/cmd/baz.c /usr/src/cmd/mumble.c
> /usr/src/cmd/bletch.c /usr/src/cmd/quux.c
> /usr/src/cmd/foo.c
>
> which contains a lot of redundant information and requires more
> columns because of that.
>
> The ideal would be a filter which did this correctly. However,
> I don't have time nor much inclination to write it.
>
Interesting. The "ls" command I wrote for MS-DOS machines does it the "ideal"
way, except that the "-C" flag is not needed -- that's the default condition.
The source was posted to net.sources about a year ago. Doesn't work on Unix
machines, though. Sorry.
--
Ed Nather
Astronomy Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
nather%utastro...@ut-sally.ARPA
Daniel R. Levy
>extra info too. Found I don't bother to use it. Anyone want a copy?
Please post to net.sources?
--
------------------------------- Disclaimer: The views contained herein are
| dan levy | yvel nad | my own and are not at all those of my em-
| an engihacker @ | ployer, my pets, my plants, my boss, or the
| at&t computer systems division | s.a. of any computer upon which I may hack.
| skokie, illinois |
| "go for it" | Path: ..!ihnp4!ttrdc!levy
-------------------------------- or: ..!ihnp4!iheds!ttbcad!levy
Doug Gwyn <gwyn>
> > yes, stty is no longer included in official System V Release 2 documentation,
> > but it is still there in the kernal (it calls ioctl).
>
> If it's there it should be documented or porters will eat it. What are the
> parameters & structures this version accepts? V6 or V7?
Stty/gtty are there for binary compatibility, not for use in new code.
Thus it doesn't matter if stty/gtty are removed during porting.
Peter da Silva
>
> Why not have a command called "vis" (as I believe P of K&P
> has suggested) which does the job of "cat -v"? Nobody's
On our system it's called "type". The only sensible option I can think
of for cat is "-u" for "unbuffered". Why do you think "~%take" in cu
generates a "tee /dev/null" command on the remote system? Sometimes an
unbuffered file copy is useful.
--
Peter da Silva (the mad Australian)
UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
MCI: PDASILVA; CIS: 70216,1076
Peter da Silva
> > your XT.
>
> That's a remarkably irrelevant example, considering 1) it has nothing to do
> with internal vs. external releases and 2) since MVS is written in 360
> assembler and PL/S, and since the former *can't* run on an 8088 without a
> slow simulator and the latter probably has lots of 360-dependent goo in it,
> you couldn't run MVS on a PC anyway.
OK. Take any IBM operating system and stick it in there. I'm not an expert
on IBM.
> > Also most "non AT&T" UNIX systems predate System V. The ones that claim to
> > be System III are almost all Microsoft or Unisoft releases
>
> The HP ones? The CCI one? (more on that one later) The Plexus one?
No, just most. A goodly percentage are TRS-80 model 16s.
> > and are V7 with SIII patches
>
> So what? The TTY driver seems to be your primary source of dyspepsia; I
> suspect most systems which are "V7 with S3 patches" have S3 libraries and a
> kernel which started out as a V7 kernel and got changed to resemble S3,
> including having the S3 tty driver dropped into it (I know that's how the
> CCI system was done, since I was one of the people who did it). As such,
> well, if it looks like a duck, and walks like a duck, and quacks like a
> duck, who cares if it's a goose with duck patches?
It doesn't quack like a duck since I took a program from V7 to Unisoft SIII
and compiled it and it ran. No problems.
> > (which is why I didn't have to know about MIN & TIME when I was working
> > on Xenix 3.0. Nice of Microsoft to tell me).
>
> This has been explained to you elsewhere, but if you're clearing the ICANON
Yes, it was explained by the OEM the "SIII" came from, after I asked him
why the SIII wasn't SV compatible.
> bit, you either have to set MIN and TIME to get reliable results or they
> botched the tty driver.
They didn't appear to have attempted to convert the TTY driver. VMIN and
VTIME should never have been part of c_cc[] in the first place, so if they
had converted it and made them seperate somewhere I'd hardly call it a botch.
> Guy Harris
Peter da Silva (wondering why he's still flaming me over VMIN and VTIME).
PS: I don't know what current Xenix3 or Uniplus+ are like, so if they have
"fixed" these "bugs" since the systems I was trying to port things between
were released don't flame me for that. I get enough of it from Guy & Bill.
Peter da Silva
> the majority, not you.
The majority will also have better things than ls for looking at directories.
Like, say, icons? And have you ever done windowing at 300, 1200, or even 2400
baud?
> Excuse me, but it is not AT&T that is putting in special cases! And why is
> accounting a special case? You are perfectly free to turn off and remove all
> accounting stuff from your 7300 ( This is complete speculation on my part,
> but they couldn't have shpxrq(ROT 13) it up THAT badly, could they? )
It was my understanding from reading the manuals that it was implemented in
the kernal, and thus couldn't be removed. I've been informed that this is
not true. (wipes egg off face)
Brandon Allbery
Quoted from <9360...@siemens.UUCP> ["Re: 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!b...@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
Henry Spencer
> 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
G.R.Tomasevich
>
> a C program. ls | pr -t -5 takes FOREVER to run! And the Plexus P/35 is
Shell scripts do not run so fast on a VAX, either, if it is heavily loaded.
I avoid them like the plague expect for setting up and checking the
arguments to C programs. A shell program is good if I do not need the
output particularly soon, but if I am doing real work, give me a C program.
--
George Tomasevich, ihnp4!twitch!grt
AT&T Bell Laboratories, Holmdel, NJ