instability in Berkeley versus A

[haahr at 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