The Dark Ages of Printing

Bill's LFS Login lfsbill at
Tue Jul 1 14:37:38 PDT 2003

On Tue, 1 Jul 2003, Ulrich Fahrenberg wrote:

> Sorry to open yet another thread on The Printing Issue, but I have
> lost track.

That's ok. There are so many tracks, you'll soon find another!  ;)

> My new version of the Printing Minority Report didn't appear on
> hints.lfs yet, giving me the opportunity to do some adjustments. Most
> notably, gv now works with my "dumb" lpr script, and I have decided
> to change the name to PrintingFromScratch.

There was one thng in the new hint that gave me pause - a typo? Where you
show creating /tmp/tmpfile, it is followed by a space and <your file>. I
first thought you had meant to replace tmpfile with <your file> and then
I thought it should be /tmp/tmpfile/<yourfile>, but that didn't make
sense. After reading the rest of the doc, I guess <your file> was meant
as a comment? But the form <...> is commonly understood to mean "plug in
your value in place of this".

Other than that, it looks quite concise and complete.

> Just so that we all know what we are talking about when refering to
> the Printing Minority Report, I have attached the (much shortened
> compared to the original) hint here.
> About the one-document-for-all-printing-needs suggestion: I vote
> against it; I'm much more into one-document-for-one-specific-need.

The one-for-one approach has the advantage of easier understanding for
most folks and also harkens back to the original UNIX concepts of one
function done well. But a consolidated one could be much more globally
useful (until "The Next Big Thing" in printing, at which time it might be
a maintenance nightmare). I think a single printing-index doc, with
*some* useful text included, that points to single-purpose docs could be
quite handy.

> <snip>

> uli

I noticed you touched on a couple potential security concerns in the doc
when talking about making print available to multiple users. These can be
addressed with *very* little change to your script if you attach the
script to the read end of a FIFO (aka named pipe). Add just a minimal
protocol, make the pipe writable by all and you have a reasonably secure
multi-user print capability. Since your script would now be a daemon, you
would want a simple startup/shutdown capability that was not dependent on
the FIFO. The trouble with doing this a small piece at a time is that
when you finish adding a small feature, you find it was so easy you are
tempted to add another, and another, ... Then some fool calls your stuff
"bloat" :-\

Just a couple thoughts.

Bill Maltby
lfsbill at
Unsubscribe: send email to listar at
and put 'unsubscribe blfs-support' in the subject header of the message

More information about the blfs-support mailing list