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!burl!ulysses!allegra!princeton!siemens!haahr From: haahr@siemens.UUCP Newsgroups: net.unix-wizards Subject: Re: Re: instability in Berkeley versus A Message-ID: <93600012@siemens.UUCP> Date: Mon, 5-Aug-85 12:40:00 EDT Article-I.D.: siemens.93600012 Posted: Mon Aug 5 12:40:00 1985 Date-Received: Tue, 6-Aug-85 10:33:29 EDT References: <9638@ucbvax.UUCP> Lines: 111 Nf-ID: #R:ucbvax:-963800:siemens:93600012:000:5159 Nf-From: siemens!haahr Aug 5 12:40:00 1985 > > 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 kre@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