cat -u

[John Chambers]

In article <8160 at bloom-beacon.MIT.EDU>, scs at athena.mit.edu (Steve Summit) writes:
> In article <4864 at bsu-cs.UUCP> dhesi at bsu-cs.UUCP (Rahul Dhesi) writes:
> >I have a shell script containing the line:
> >
> >     /bin/cat -uv "$file" | /usr/ucb/more -10d
> 
> Which is exactly why an option like -v (make control characters
> visible) should be in a file-viewing utility like more, and not
> in a concatenation utility like cat.

Nah; you're both wrong.  It belongs in a separate program that does
only that one job, and the above pipeline should have three processes,
not two.

It doesn't belong in more, because it's useful in situations other
than just displaying on a terminal.  I've written silly little
filters like this on many occasions, and I've invariably been 
glad that I wrote them as separate programs, so I could interpose
them between random pairs of other programs.

It also doesn't belong in more, because more's job is to paginate,
and it shouldn't have to do extraneous junk like text translation.
Suppose I want some other translation other than the one programmed
into more?  I'm outa luck, right?  If it's a separate process, then
I can develop a repertoire of them for different terminals or different
languages or ..., and the user can call the right one.

You could make a feeble argument that it's at least OK to put it
into cat.  This makes "| cat -v |" the character-translate process
in the pipeline.  But cat's real job is to catenate files.  It
shouldn't do anything other than that.

What ever happened to the original Unix Philosophy of lots of little
programs, each of which did exactly one job well, and which could be
fitted together to do bigger jobs?  I've noticed that lots of people
seem to dislike this approach, but I've yet to see any cogent argument
against it.

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]