> [1] The chances that I want Postscript output as plain text out of a
> *printer* (think about how much paper that is...) are maybe 1 in
> 1000,

You must not write much PostScript.  I frequently want to print the
very same file twice, once rendered as PostScript and once printed as
plain text.  (Not all PostScript files produce reams and reams of paper
when printed as text.)

> and I can go to some special effort to make it happen;

The printing mechanism I use ("nc iiisi 9100") _always_ takes
PostScript, so there is no ambiguity.  Every lpr I've seen tries to
guess whether it's being fed text or PostScript, and at least for me
guesses wrong relatively often (as it must, since the difference is
sometimes entirely in the intent of the person printing it).  This is
not inherently a problem; what *is* a problem is that lprs I've seen
don't have any way to override this guess in the case of
PostScript-vs-text, up to and including lpr.1,v 1.12.  This is one of
my main objections to using lpr.

> anyway, we *already* grovel file contents for things like file(1)...
> do you disapprove of that?

No, because that is file's raison d'etre.

cc compiles C code; should lpr thus compile any C code it's fed?
"anyway, we *already* compile C code in things like cc(1)..."
Of course not.  And no more is file(1) doing content type guessing a
reason for lpr to do it.

> Can you show an example of when CUPS got this wrong in the real
> world?

I can't because I don't use CUPS.  But as I mentioned above, I
certainly can give examples of cases where whichever way any software
guesses, it would guess wrong at least once.  (Assuming, of course,
that its guess is driven entirely off the file's contents.  Random
guessing could potentially not guess wrong at all.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B