Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!ihnp4!ucbvax!kre From: kre@ucbvax.ARPA (Robert Elz) Newsgroups: net.unix-wizards Subject: Re: instability in Berkeley versus AT&T releases (absurdly long) Message-ID: <9638@ucbvax.ARPA> Date: Sun, 4-Aug-85 10:51:57 EDT Article-I.D.: ucbvax.9638 Posted: Sun Aug 4 10:51:57 1985 Date-Received: Mon, 5-Aug-85 07:40:39 EDT References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp> <5819@utzoo.UUCP>, <5852@utzoo.UUCP> Organization: University of California at Berkeley Lines: 76 Keywords: ls -C Summary: How come its OK for 'ls' to sort, but not columnise??? In article <5852@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > > 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. (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 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...