Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: $Revision: 1.6.2.14 $; site siemens.UUCP Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!edsel!bentley!ihnp1!ihnp4!mhuxn!mhuxr!ulysses!allegra!princeton!siemens!haahr From: haahr@siemens.UUCP Newsgroups: net.unix-wizards Subject: Re: Re: instability in Berkeley versus A Message-ID: <93600010@siemens.UUCP> Date: Mon, 5-Aug-85 11:41:00 EDT Article-I.D.: siemens.93600010 Posted: Mon Aug 5 11:41:00 1985 Date-Received: Tue, 6-Aug-85 09:58:58 EDT References: <1303@utcsri.UUCP> Lines: 103 Nf-ID: #R:utcsri:-130300:siemens:93600010:000:5299 Nf-From: siemens!haahr Aug 5 11:41:00 1985 > > For an explanation of why "one program, one function, done well" is a good > > way to build a system, see almost any discussion of the "Unix philosophy". > > Try Kernighan & Pike. > > -- > > Henry Spencer @ U of Toronto Zoology > > {allegra,ihnp4,linus,decvax}!utzoo!henry > > _Software Tools_, pg. 84 (Kernighan & Pike): Hate to be picky, but _Software_Tools_ was written by Kernighan and P. J. Plauger (of Whitesmiths). But it is a great source for Unix philosophy. > Efficiency is hardly of importance for a temporary hookup > meant only to be used a few times. Should a particular > organization of tools prove so useful that it begins to > consume significant resources, then you can consider > replacing it with a more efficient version. And you are > way ahead at this point, for you are writing a program > that has precise specifications and that has been shown > to be useful. > > I think columnar ls is a case in point, though perhaps a bit trivial to > really worry about. From the human perspective, it is much more > pleasant, and doesn't waste my time scrolling the listing off the > screen. And if it is used heavily, why not incorporate it? ... The definitive argument against Berkeley ls is in _Program_Design_in_ _the_UNIX_System_Environment_, by (would you believe) Kernighan & Pike, BSTJ, October 1984, specifically pages 1601-1603. To quote: (note that the authors refer to Berkeley ls as lsc) Surprisingly, lsc operates differently if its output is a file or a pipe: lsc produces output different from lsc | cat The reason is that lsc begins by examining whether its output is a terminal, and prints its output in columns only if it is. By retaining single-column output to files or pipes, lsc retains compatibility with programs like grep or wc, which expect things to be printed one per line... A more insidious problem with lsc is the columnation facility, which is actually a useful, general function, is built in and thus inaccessible to other programs that could use a similar compression. The authors then suggest a general purpose filter (based on pr) that would take its output and columnate it. So, for five-column output from ls: ls | 5 On your concern for efficiency, the only avoidable answer is yes, the two command version is slower and does involve more typing. On typing, create a shell script ll (or whatever) that does ls $* | 5 or, for people who like to see /*=@ etc after filenames ls -F $* | 5 If your shell provides aliasing or shell functions this is even easier. This is, of course, slower than Berkeley ls, except ls wouldn't have to check where it's output is going (one isatty call), so a vanilla ls piping its output to grep will work faster. Plus, for a command that is executed interactively (I can think of very few occasions when one would want to have columnar ls output to a terminal from something that is time critical), I would doubt that the big problem comes from between pipes I have tried using an 'll' which is a csh alias for a pipe and can't notice difference (VAX-11/750, unloaded). My point here is basically that you are talking about gaining a trivial amount efficiency in exchange for elegance and simplicity. > ... I agree with > modular, single function boxes, but there should be some quarter given > to practicality here; if it is used heavily, that is your license to > incorporate it into the code. I won't argue the more esoteric features > of ls. The point is, I think, that there are several levels of use: > One-function boxes strung together with pipes, shell scripts, and for > the most heavily used features that have made it to the level of > 'heavily used shell scripts', C coding, or inclusion into an existing > binary program. I see no justification for the religious statement > "Thou shalt code in sh." It is a relative, sliding scale that leaves > room for things like Berkley ls. Not to say that they have never > over-done it, mind you... They have overdone it all too often it seems. If Berkeley had provided a general purpose columnation command (even better if it was termcap sensitive rather than fixed 80-columns) and had found that a lot of people had aliases or shell scripts that piped ls to this program and found a way to keep it compatible with existing use (I don't like having programs like ls checking if their output is a terminal) and there was a big win in speed observed by hacking the code into ls, then, yes, maybe they should do ls -C, but the Berkeley approach seems to be: gee, output from ls (and no other program? :-) runs off the screen a lot. Why don't I fix (break?) ls so that doesn't happen. But I don't want to affect any program that looks at ls, only what a user sees. And only if they decide not to use a filter like more for those really large directories. The Berkeley philosophy is reminiscent of the FORTRAN programmer in _Software_Tools_'s first chapter, who has the clever idea of not using a red pencil to find all FORMAT statements in his program, but instead writes a program that searches for the word FORMAT. Now that they have proven that columnation of output is useful, why not provide a general purpose way of doing it? Paul Haahr ..!allegra!princeton!macbeth!haahr