1LP(1P) POSIX Programmer's Manual LP(1P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
13 lp — send files to a printer
14
16 lp [−c] [−d dest] [−n copies] [−msw] [−o option]... [−t title] [file...]
17
19 The lp utility shall copy the input files to an output destination in
20 an unspecified manner. The default output destination should be to a
21 hardcopy device, such as a printer or microfilm recorder, that produces
22 non-volatile, human-readable documents. If such a device is not avail‐
23 able to the application, or if the system provides no such device, the
24 lp utility shall exit with a non-zero exit status.
25 The actual writing to the output device may occur some time after the
27 lp utility successfully exits. During the portion of the writing that
28 corresponds to each input file, the implementation shall guarantee
29 exclusive access to the device.
30 The lp utility shall associate a unique request ID with each request.
32 Normally, a banner page is produced to separate and identify each print
34 job. This page may be suppressed by implementation-defined conditions,
35 such as an operator command or one of the −o option values.
36
38 The lp utility shall conform to the Base Definitions volume of
39 POSIX.1‐2008, Section 12.2, Utility Syntax Guidelines.
40 The following options shall be supported:
42 −c Exit only after further access to any of the input files is
44 no longer required. The application can then safely delete or
45 modify the files without affecting the output operation. Nor‐
46 mally, files are not copied, but are linked whenever possi‐
47 ble. If the −c option is not given, then the user should be
48 careful not to remove any of the files before the request has
49 been printed in its entirety. It should also be noted that in
50 the absence of the −c option, any changes made to the named
51 files after the request is made but before it is printed may
52 be reflected in the printed output. On some implementations,
53 −c may be on by default.
54 −d dest Specify a string that names the destination (dest). If dest
56 is a printer, the request shall be printed only on that spe‐
57 cific printer. If dest is a class of printers, the request
58 shall be printed on the first available printer that is a
59 member of the class. Under certain conditions (printer
60 unavailability, file space limitation, and so on), requests
61 for specific destinations need not be accepted. Destination
62 names vary between systems.
63 If −d is not specified, and neither the LPDEST nor PRINTER
65 environment variable is set, an unspecified destination is
66 used. The −d dest option shall take precedence over LPDEST,
67 which in turn shall take precedence over PRINTER. Results
68 are undefined when dest contains a value that is not a valid
69 destination name.
70 −m Send mail (see mailx) after the files have been printed. By
72 default, no mail is sent upon normal completion of the print
73 request.
74 −n copies Write copies number of copies of the files, where copies is a
76 positive decimal integer. The methods for producing multiple
77 copies and for arranging the multiple copies when multiple
78 file operands are used are unspecified, except that each file
79 shall be output as an integral whole, not interleaved with
80 portions of other files.
81 −o option Specify printer-dependent or class-dependent options. Sev‐
83 eral such options may be collected by specifying the −o
84 option more than once.
85 −s Suppress messages from lp.
87 −t title Write title on the banner page of the output.
89 −w Write a message on the user's terminal after the files have
91 been printed. If the user is not logged in, then mail shall
92 be sent instead.
93
95 The following operand shall be supported:
96 file A pathname of a file to be output. If no file operands are
98 specified, or if a file operand is '−', the standard input
99 shall be used. If a file operand is used, but the −c option
100 is not specified, the process performing the writing to the
101 output device may have user and group permissions that differ
102 from that of the process invoking lp.
103
105 The standard input shall be used only if no file operands are speci‐
106 fied, or if a file operand is '−'. See the INPUT FILES section.
107
109 The input files shall be text files.
110
112 The following environment variables shall affect the execution of lp:
113 LANG Provide a default value for the internationalization vari‐
115 ables that are unset or null. (See the Base Definitions vol‐
116 ume of POSIX.1‐2008, Section 8.2, Internationalization Vari‐
117 ables for the precedence of internationalization variables
118 used to determine the values of locale categories.)
119 LC_ALL If set to a non-empty string value, override the values of
121 all the other internationalization variables.
122 LC_CTYPE Determine the locale for the interpretation of sequences of
124 bytes of text data as characters (for example, single-byte as
125 opposed to multi-byte characters in arguments and input
126 files).
127 LC_MESSAGES
129 Determine the locale that should be used to affect the format
130 and contents of diagnostic messages written to standard error
131 and informative messages written to standard output.
132 LC_TIME Determine the format and contents of date and time strings
134 displayed in the lp banner page, if any.
135 LPDEST Determine the destination. If the LPDEST environment variable
137 is not set, the PRINTER environment variable shall be used.
138 The −d dest option takes precedence over LPDEST. Results are
139 undefined when −d is not specified and LPDEST contains a
140 value that is not a valid destination name.
141 NLSPATH Determine the location of message catalogs for the processing
143 of LC_MESSAGES.
144 PRINTER Determine the output device or destination. If the LPDEST and
146 PRINTER environment variables are not set, an unspecified
147 output device is used. The −d dest option and the LPDEST
148 environment variable shall take precedence over PRINTER.
149 Results are undefined when −d is not specified, LPDEST is
150 unset, and PRINTER contains a value that is not a valid
151 device or destination name.
152 TZ Determine the timezone used to calculate date and time
154 strings displayed in the lp banner page, if any. If TZ is
155 unset or null, an unspecified default timezone shall be used.
156
158 Default.
159
161 The lp utility shall write a request ID to the standard output, unless
162 −s is specified. The format of the message is unspecified. The request
163 ID can be used on systems supporting the historical cancel and lpstat
164 utilities.
165
167 The standard error shall be used only for diagnostic messages.
168
170 None.
171
173 None.
174
176 The following exit values shall be returned:
177 0 All input files were processed successfully.
179 >0 No output device was available, or an error occurred.
181
183 Default.
184 The following sections are informative.
186
188 The pr and fold utilities can be used to achieve reasonable formatting
189 for the implementation's default page size.
190 A conforming application can use one of the file operands only with the
192 −c option or if the file is publicly readable and guaranteed to be
193 available at the time of printing. This is because POSIX.1‐2008 gives
194 the implementation the freedom to queue up the request for printing at
195 some later time by a different process that might not be able to access
196 the file.
197
199 1. To print file file:
200 lp −c file
202 2. To print multiple files with headers:
204 pr file1 file2 | lp
206
208 The lp utility was designed to be a basic version of a utility that is
209 already available in many historical implementations. The standard
210 developers considered that it should be implementable simply as:
211 cat "$@" > /dev/lp
213 after appropriate processing of options, if that is how the implementa‐
215 tion chose to do it and if exclusive access could be granted (so that
216 two users did not write to the device simultaneously). Although in the
217 future the standard developers may add other options to this utility,
218 it should always be able to execute with no options or operands and
219 send the standard input to an unspecified output device.
220 This volume of POSIX.1‐2008 makes no representations concerning the
222 format of the printed output, except that it must be ``human-readable''
223 and ``non-volatile''. Thus, writing by default to a disk or tape drive
224 or a display terminal would not qualify. (Such destinations are not
225 prohibited when −d dest, LPDEST, or PRINTER are used, however.)
226 This volume of POSIX.1‐2008 is worded such that a ``print job'' con‐
228 sisting of multiple input files, possibly in multiple copies, is guar‐
229 anteed to print so that any one file is not intermixed with another,
230 but there is no statement that all the files or copies have to print
231 out together.
232 The −c option may imply a spooling operation, but this is not required.
234 The utility can be implemented to wait until the printer is ready and
235 then wait until it is finished. Because of that, there is no attempt to
236 define a queuing mechanism (priorities, classes of output, and so on).
237 On some historical systems, the request ID reported on the STDOUT can
239 be used to later cancel or find the status of a request using utilities
240 not defined in this volume of POSIX.1‐2008.
241 Although the historical System V lp and BSD lpr utilities have provided
243 similar functionality, they used different names for the environment
244 variable specifying the destination printer. Since the name of the
245 utility here is lp, LPDEST (used by the System V lp utility) was given
246 precedence over PRINTER (used by the BSD lpr utility). Since environ‐
247 ments of users frequently contain one or the other environment vari‐
248 able, the lp utility is required to recognize both. If this was not
249 done, many applications would send output to unexpected output devices
250 when users moved from system to system.
251 Some have commented that lp has far too little functionality to make it
253 worthwhile. Requests have proposed additional options or operands or
254 both that added functionality. The requests included:
255 * Wording requiring the output to be ``hardcopy''
257 * A requirement for multiple printers
259 * Options for supporting various page-description languages
261 Given that a compliant system is not required to even have a printer,
263 placing further restrictions upon the behavior of the printer is not
264 useful. Since hardcopy format is so application-dependent, it is diffi‐
265 cult, if not impossible, to select a reasonable subset of functionality
266 that should be required on all compliant systems.
267 The term unspecified is used in this section in lieu of implementation-
269 defined as most known implementations would not be able to make defini‐
270 tive statements in their conformance documents; the existence and usage
271 of printers is very dependent on how the system administrator config‐
272 ures each individual system.
273 Since the default destination, device type, queuing mechanisms, and
275 acceptable forms of input are all unspecified, usage guidelines for
276 what a conforming application can do are as follows:
277 * Use the command in a pipeline, or with −c, so that there are no
279 permission problems and the files can be safely deleted or modi‐
280 fied.
281 * Limit output to text files of reasonable line lengths and printable
283 characters and include no device-specific formatting information,
284 such as a page description language. The meaning of ``reasonable''
285 in this context can only be answered as a quality-of-implementation
286 issue, but it should be apparent from historical usage patterns in
287 the industry and the locale. The pr and fold utilities can be used
288 to achieve reasonable formatting for the default page size of the
289 implementation.
290 Alternatively, the application can arrange its installation in such a
292 way that it requires the system administrator or operator to provide
293 the appropriate information on lp options and environment variable val‐
294 ues.
295 At a minimum, having this utility in this volume of POSIX.1‐2008 tells
297 the industry that conforming applications require a means to print out‐
298 put and provides at least a command name and LPDEST routing mechanism
299 that can be used for discussions between vendors, application develop‐
300 ers, and users. The use of ``should'' in the DESCRIPTION of lp clearly
301 shows the intent of the standard developers, even if they cannot man‐
302 date that all systems (such as laptops) have printers.
303 This volume of POSIX.1‐2008 does not specify what the ownership of the
305 process performing the writing to the output device may be. If −c is
306 not used, it is unspecified whether the process performing the writing
307 to the output device has permission to read file if there are any
308 restrictions in place on who may read file until after it is printed.
309 Also, if −c is not used, the results of deleting file before it is
310 printed are unspecified.
311
313 None.
314
316 mailx
317 The Base Definitions volume of POSIX.1‐2008, Chapter 8, Environment
319 Variables, Section 12.2, Utility Syntax Guidelines
320
322 Portions of this text are reprinted and reproduced in electronic form
323 from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
324 -- Portable Operating System Interface (POSIX), The Open Group Base
325 Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
326 cal and Electronics Engineers, Inc and The Open Group. (This is
327 POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
328 event of any discrepancy between this version and the original IEEE and
329 The Open Group Standard, the original IEEE and The Open Group Standard
330 is the referee document. The original Standard can be obtained online
331 at http://www.unix.org/online.html .
332 Any typographical or formatting errors that appear in this page are
334 most likely to have been introduced during the conversion of the source
335 files to man page format. To report such errors, see https://www.ker‐
336 nel.org/doc/man-pages/reporting_bugs.html .
337IEEE/The Open Group 2013 LP(1P)