Template:Short description The printing subsystem of UNIX System V is one of several standardized systems for printing on Unix, and is typical of commercial System V-based Unix versions such as Solaris and SCO OpenServer. A system running this print architecture could traditionally be identified by the use of the user command Template:Mono as the primary interface to the print system, as opposed to the BSD [[Line Printer Daemon protocol|Template:Mono]] command (though some systems provide Template:Mono as an alias to Template:Mono).
Typical user commands available to the System V printing system are:
- Template:Mono: the user command to print a document
- Template:Mono: shows the current print queue
- Template:Mono: deletes a job from the print queue
- Template:Mono: a system administration command that configures the print system
- Template:Mono: a system administration command that moves jobs between print queues
HistoryEdit
In the Unix programming model, device files are special files that act as access points to peripheral devices such as printers. For example, the first line printer on a Unix system might be represented by a file Template:Mono in the device (Template:Mono) directory, i.e., Template:Mono. Using the file metaphor, a document could by printed by "copying" the file onto the device: Template:Mono. While this worked well enough for the case where there was one printer per user, this model did not scale out well to multiple users having to share one printer.<ref name=Kofler1997/> The solution was to create a queue (or "spool") of documents to be printed and use a daemon (system process) to manage this queue and send the documents to the printer in the order in which they arrived.
Such a system, with an Template:Mono command to send documents to the queue, was first introduced in 1973 in Version 4 of Unix.Template:R By the release of System V Release 4, the suite of utilities had grown to include commands for canceling print jobs, moving jobs among queues, enabling and disabling queues, enabling and disabling a job scheduler daemon, and status reports of the print system.Template:R The Template:Mono command handled queue documents to be printedTemplate:R and had over 20 different options that controlled the appearance of the document and its place in the queue,Template:R and even handled email notification of the user once the document had finished printing.Template:R The command returned a "job id" which could be used by the cancel or lpstat commands to remove the job from the queue or check on its progress, respectively.Template:R While the system was considered to be quite complex to set up and administer, most uses were expected to only use these three commands.Template:R
With its distribution in the influential AT&T Unix System V, the interface if not the implementation became the standard for users' control over printers. The Template:Mono command was included as a requirement in the POSIX.2 standard,<ref name=Gardner1994/> and a command by that name appeared in the subsequent lpr, LPRng and CUPS printing systems. (In SVR4 derivates like SCO UNIX, the Template:Mono command was simply an alias for the Template:Mono command used by the BSD-based Template:Mono system.<ref name=Cutler1994/>)
As late as 1996, Running Linux stated "The Linux printing software consists of the UNIX standard lp and lpr software,"<ref name=Welsh1995/> but by 1999 support for lp was waning and the third edition simply stated "The lpr command prints a document on Linux."<ref name=Welsh1999/> By 2003, a survey of the Debian, Mandrake, Red Hat, Slackware and SuSE distributions showed that all of them were running some combination of lpr, LPRng and CUPS.<ref name=Smith2003/>
The original System V printing system remains proprietary; however, the Solaris print system, heavily modified from the original, has been released as open source software as part of the OpenSolaris project. The Common Unix Printing System emulates both System V and Berkeley print architectures on the interface level, though its internal architecture is different from both.
CriticismEdit
In his introduction to a simplified configuration system for lp, author Peter Gray of the University of Wollongong described several weaknesses of the version shipping with the then-current Solaris (operating system) version 2.
- As opposed to the single daemon used by the simpler BSD lpr system, the lp system used separate daemons, one for scheduling and one for remote communication.
- The lpr system could be controlled with a single configuration file while lp requires a separate program for administration.
- The lp system did support permissions, but the model did not scale to hundreds of users.
As a result, Gray observed that "many administrators choose to simply run the old lpr/lpd system on the SVR4 boxes."<ref name=Gray1997/>