ls holy wars
Brandon Allbery
bsa at ncoast.UUCP
Tue Aug 13 12:02:51 AEST 1985
Expires:
Quoted from <93600010 at siemens.UUCP> ["Re: Re: instability in Berkeley versus A"], by haahr at 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!bsa at 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
More information about the Comp.unix.wizards
mailing list