Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: cat -v and ls -C considered harmful Message-ID: <2578@sun.uucp> Date: Thu, 8-Aug-85 05:37:46 EDT Article-I.D.: sun.2578 Posted: Thu Aug 8 05:37:46 1985 Date-Received: Mon, 12-Aug-85 00:39:18 EDT References: <1303@utcsri.UUCP> <93600010@siemens.UUCP> Organization: Sun Microsystems, Inc. Lines: 89 Why "cat -v" may be bad, even though the functionality it provides is good: Why not have a command called "vis" (as I believe P of K&P has suggested) which does the job of "cat -v"? Nobody's arguing that there's no need for a program to send files to the terminal (or elsewhere) with control characters escaped. "cat" isn't the "official" file-typing program on UNIX; its official role is to concatenate several files and send the result to the standard output. (That's why the seemingly-strange name which people who want to poke fun at UNIX pick on.) A consequence of this is that it can be used to type files. Most of the time *I* use "more", not "cat", to type files, because I 1) don't like data scrolling off my screen and 2) don't like the "built-in" pager that the window system here has. It's somewhat a question of whether adding the extra functionality to "cat" 1) slows "cat" down (which it *will* do if the same path is used for "cat -v" and "cat", since the former must inspect each character as it goes by and the latter need not), 2) makes "cat" into two independent programs with a small bit of connective tissue holding them together (which it will do if different paths are used for "cat" and "cat -v", or 3) makes the system conceptually more complex by bundling two (or more) distinct functions into one program. Why "ls | pr" isn't good enough, but why "ls -C" might not be the best solution: I *VERY* frequently do things like ls * when the current directory is full of directories. When used with the Berkeley "ls" (or the S5R2 "ls" with the "-C" flag), this gives me an extremely attractive and easy to read listing of the form: directory1: file1 file2 file3 directory2: file1 file3 file5 file6 file7 file8 file2 file4 "ls | pr", or "ls | any_other_general_filter", can't do this because it doesn't know that its input is coming from "ls" (that's because it *is* a general filter) and can't tell the difference between directory name headers and file names. A filter to decipher the output of a single-column "ls" (including recognizing the difference between a heading like "directory1:" and a file whose name ends with colon - this may sound trivial but not doing this correctly is just sloppy) and put it into this format would be very nice - and probably useless for anything other than piping "ls" into. *I* refuse to accept any multi-column-listing solution which can't produce that kind of output for "ls <-C> *", no matter how conceptually correct it is. However, ls -C /usr/src/cmd/*.c doesn't really do the optimal thing, either. On a DEC or other system where file-name expansion is done in the program, rather than in the shell, the program would know enough to say: /usr/src/cmd: bar.c bletch.c frotz.c mumble.c quux.c baz.c foo.c which is the ideal format for human consumption. Both Berkeley's and the USDL's "ls" will, instead, do /usr/src/cmd/bar.c /usr/src/cmd/frotz.c /usr/src/cmd/baz.c /usr/src/cmd/mumble.c /usr/src/cmd/bletch.c /usr/src/cmd/quux.c /usr/src/cmd/foo.c which contains a lot of redundant information and requires more columns because of that. The ideal would be a filter which did this correctly. However, I don't have time nor much inclination to write it. Moral: religious questions, like other questions, don't always have simple answers. Guy Harris