guy@sun.uucp (Guy Harris) (08/08/85)
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
nather@utastro.UUCP (Ed Nather) (08/09/85)
> 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. > > Guy Harris Interesting. The "ls" command I wrote for MS-DOS machines does it the "ideal" way, except that the "-C" flag is not needed -- that's the default condition. The source was posted to net.sources about a year ago. Doesn't work on Unix machines, though. Sorry. -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather%utastro.UTEXAS@ut-sally.ARPA
peter@baylor.UUCP (Peter da Silva) (08/12/85)
> 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 On our system it's called "type". The only sensible option I can think of for cat is "-u" for "unbuffered". Why do you think "~%take" in cu generates a "tee /dev/null" command on the remote system? Sometimes an unbuffered file copy is useful. -- Peter da Silva (the mad Australian) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076