cat -v and ls -C considered harmful

[Guy Harris]

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