As described in the Print Spooling Overview, the heart of the LPRng system is information in the printcap file. The printcap information specifies:
The print queues available to users.
How client programs communicate with the lpc print server.
The configuration, location, and other information for each print queue on the print server.
How the lpd server processes jobs in each print queue.
In order to explain a complex subject, we will start with a set of simple printer configurations, and explain the purpose and effect of each entry in the printcap.
For details about individual printcap options, see the printcap(5) man page from the LPRng distribution, or use the Index To All The Configuration and Printcap Options to find a specific printcap option and its effects.
Options used:
client FLAG printcap entry valid only for client programs
oh=hosts where printcap entry valid
serverprintcap entry valid only for lpd server
tcadd named printcap entry contents
In this section, we will discuss the remaining tricky parts of the LPRng printcap database: combined client and server printcaps, host specific printcap entries, and the tc include facility.
The following is a complete description of how a printcap file is processed:
When processing a printcap file, the LPRng software reads and parses each entry individually. Leading whitespace is removed. Lines starting with # and blank lines are ignored.
Lines ending with \ will have the \ discarded, and all lines of a printcap entry are joined by removing the line separators (\n) and replacing them with a space.
The printcap entry is parsed, and the printcap name, aliases, and options are determined. Colons : act as option separators, and leading and trailing whitespaces are removed.
Options are sorted and except for the tc=... option only the last option setting is retained.
If an option value requires a colon, then the \: or \072, the same escaped character value as used in the C, Perl, tcl, and other programming languages, can be used.
Client programs will discard a printcap entry with a server option and server programs will discard a printcap entry with a client options.
The oh (on this host) option specifies a list of IP addresses and mask pairs or glob strings which are used to determine if this printcap entry is valid for this host (see discussion below).
After the above processing, if there is an existing termcap entry with the same name, the two sets of options are combined, with the last option setting retained except for the tc entries which are combined.
When a printcap entry is actually used, the printcap entries listed by the tc include option are extracted and combined in order. This allows include entries to appear after the referring printcap entry. Then printcap options will be combined with the included ones. This has the effect that the options specified in the printcap entry will override the ones from the tc included entries.
Finally, each string printcap option with a %X value has %X replaced by the following values. Unspecified values will not be modified.
| Key | Value | Purpose |
|---|---|---|
| %P | printcap entry primary name | |
| %Q | queue requested | |
| %h | short host name (host) | |
| %H | fully qualified host name (host.dns.whatever) | |
| %R | remote printer (rp value) | |
| %M | remote host (rm value) | |
| %D | date in YYYY-MM-DD format |
When parsing multiple printcap files, these are processed in order, and all of their printcap entries are combined according to the above procedures. The tc resolution and %X expansion is done after all the files have been processed.
The following examples show how to use the above rules to your advantage. You can combine both client and server printcap information in a single file as well as dividing a printcap entry into several parts. Here is an example:
# seen by both client and server
lp1:lp=lp@pr1:mx=100
lp1:sd=/usr/local/spool/lp1:mx=0
# seen only by client
lp2:lp=lp@pr2:client
# seen only by server
lp2:lp=/dev/lp:server
Printcap entries with the same name are combined. The first printcap entry, lp1, the information is seen by both client and server. The next printcap entry, with the same name lp1, will be combined with the first one. The order of options is important - the entries are scanned in order and an option will have the last value set. Thus, after having read both the lp1 printcap entries, both client and server will have:
The lp2 has a client and server version. This is recommended when complex printcaps on multiple hosts and servers are used. Thus, the LPRng clients will see:
and the server will see:If you have multiple printers of the same type whose configuration is almost identical, then you can define a set of tc only printcap entries containing common information and use the tc include facility.
Printcap entry names may start with period (.), question mark (?), or exclamation mark (!), followed by one or more alphanumeric , underscore (_) or hyphen (-) characters. Queue or printer names start with an alphanumeric character. Printcap entries whose names do not start with an alphanumeric character can only be used as targets of the tc include facility. For example:
.hp:
:sd=/usr/local/spool/%P
:mx=0
hp1:tc=.hp,.filter
:lp=lp@10.0.0.1
hp2:tc=.hp,.filter
:lp=lp@10.0.0.2
.filter
:filter=/usr/local/libexec/filters/ifhp
The .hp and .filter printcap entities are not spool queue definitions. After tc include processing is completed, the printcap information would resemble:
hp1
:lp=lp@10.0.0.1
:filter=/usr/local/libexec/filters/ifhp
:mx=0
:sd=/usr/local/spool/%P
hp2
:lp=lp@10.0.0.2
:filter=/usr/local/libexec/filters/ifhp
:mx=0
:sd=/usr/local/spool/%P
The %X processing will replace %P with the printcap name, so we would have:
hp1
:lp=lp@10.0.0.1
:filter=/usr/local/libexec/filters/ifhp
:mx=0
:sd=/usr/local/spool/hp1
hp2
:lp=lp@10.0.0.2
:filter=/usr/local/libexec/filters/ifhp
:mx=0
:sd=/usr/local/spool/hp2