1LP(1P)                     POSIX Programmer's Manual                    LP(1P)
2
3
4

PROLOG

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

NAME

12       lp - send files to a printer
13

SYNOPSIS

15       lp [-c][-d dest][-n copies][-msw][-o option]...  [-t title][file...]
16

DESCRIPTION

18       The lp utility shall copy the input files to an output  destination  in
19       an  unspecified  manner.  The default output destination should be to a
20       hardcopy device, such as a printer or microfilm recorder, that produces
21       non-volatile,  human-readable documents. If such a device is not avail‐
22       able to the application, or if the system provides no such device,  the
23       lp utility shall exit with a non-zero exit status.
24
25       The  actual  writing to the output device may occur some time after the
26       lp utility successfully exits. During the portion of the  writing  that
27       corresponds  to  each  input  file,  the implementation shall guarantee
28       exclusive access to the device.
29
30       The lp utility shall associate a unique request ID with each request.
31
32       Normally, a banner page is produced to separate and identify each print
33       job.  This page may be suppressed by implementation-defined conditions,
34       such as an operator command or one of the -o option values.
35

OPTIONS

37       The lp  utility  shall  conform  to  the  Base  Definitions  volume  of
38       IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.
39
40       The following options shall be supported:
41
42       -c     Exit  only  after further access to any of the input files is no
43              longer required. The application can then safely delete or  mod‐
44              ify  the files without affecting the output operation. Normally,
45              files are not copied, but are linked whenever possible.  If  the
46              -c  option  is not given, then the user should be careful not to
47              remove any of the files before the request has been  printed  in
48              its entirety. It should also be noted that in the absence of the
49              -c option, any changes made to the named files after the request
50              is made but before it is printed may be reflected in the printed
51              output. On some implementations, -c may be on by default.
52
53       -d  dest
54              Specify a string that names the destination ( dest). If dest  is
55              a  printer,  the  request shall be printed only on that specific
56              printer. If dest is a class of printers, the  request  shall  be
57              printed  on  the first available printer that is a member of the
58              class. Under certain conditions  (printer  unavailability,  file
59              space limitation, and so on), requests for specific destinations
60              need not be accepted. Destination names vary between systems.
61
62       If -d is not specified, and neither the LPDEST nor PRINTER  environment
63       variable is set, an unspecified destination is used. The -d dest option
64       shall take precedence over LPDEST,  which in turn shall take precedence
65       over PRINTER.  Results are undefined when dest contains a value that is
66       not a valid destination name.
67
68       -m     Send mail (see mailx ) after the files  have  been  printed.  By
69              default,  no  mail  is  sent upon normal completion of the print
70              request.
71
72       -n  copies
73              Write copies number of copies of the files, where  copies  is  a
74              positive  decimal  integer.  The  methods for producing multiple
75              copies and for arranging the multiple copies when multiple  file
76              operands  are  used are unspecified, except that each file shall
77              be output as an integral whole, not interleaved with portions of
78              other files.
79
80       -o  option
81              Specify  printer-dependent  or  class-dependent options. Several
82              such options may be collected by specifying the -o  option  more
83              than once.
84
85       -s     Suppress messages from lp.
86
87       -t  title
88              Write title on the banner page of the output.
89
90       -w     Write a message on the user's terminal after the files have been
91              printed.  If the user is not logged in, then mail shall be  sent
92              instead.
93
94

OPERANDS

96       The following operand shall be supported:
97
98       file   A pathname of a file to be output. If no file operands are spec‐
99              ified, or if a file operand is '-', the standard input shall  be
100              used. If a file operand is used, but the -c option is not speci‐
101              fied, the process performing the writing to  the  output  device
102              may have user and group permissions that differ from that of the
103              process invoking lp.
104
105

STDIN

107       The standard input shall be used only if no file  operands  are  speci‐
108       fied, or if a file operand is '-' .  See the INPUT FILES section.
109

INPUT FILES

111       The input files shall be text files.
112

ENVIRONMENT VARIABLES

114       The following environment variables shall affect the execution of lp:
115
116       LANG   Provide  a  default value for the internationalization variables
117              that are unset or null. (See  the  Base  Definitions  volume  of
118              IEEE Std 1003.1-2001,  Section  8.2,  Internationalization Vari‐
119              ables for the precedence of internationalization variables  used
120              to determine the values of locale categories.)
121
122       LC_ALL If  set  to a non-empty string value, override the values of all
123              the other internationalization variables.
124
125       LC_CTYPE
126              Determine the locale for  the  interpretation  of  sequences  of
127              bytes  of  text  data as characters (for example, single-byte as
128              opposed to multi-byte characters in arguments and input files).
129
130       LC_MESSAGES
131              Determine the locale that should be used to  affect  the  format
132              and  contents  of  diagnostic messages written to standard error
133              and informative messages written to standard output.
134
135       LC_TIME
136              Determine the format and contents of date and time strings  dis‐
137              played in the lp banner page, if any.
138
139       LPDEST Determine the destination. If the LPDEST environment variable is
140              not set, the PRINTER environment variable shall be used. The  -d
141              dest option takes precedence over LPDEST . Results are undefined
142              when -d is not specified and LPDEST contains a value that is not
143              a valid destination name.
144
145       NLSPATH
146              Determine the location of message catalogs for the processing of
147              LC_MESSAGES .
148
149       PRINTER
150              Determine the output device or destination. If  the  LPDEST  and
151              PRINTER environment variables are not set, an unspecified output
152              device is used. The -d dest option and  the  LPDEST  environment
153              variable  shall take precedence over PRINTER.  Results are unde‐
154              fined when -d is not specified, LPDEST  is  unset,  and  PRINTER
155              contains a value that is not a valid device or destination name.
156
157       TZ     Determine  the  timezone used to calculate date and time strings
158              displayed in the lp banner page, if any. If TZ is unset or null,
159              an unspecified default timezone shall be used.
160
161

ASYNCHRONOUS EVENTS

163       Default.
164

STDOUT

166       The  lp utility shall write a request ID to the standard output, unless
167       -s is specified. The format of the message is unspecified. The  request
168       ID  can  be used on systems supporting the historical cancel and lpstat
169       utilities.
170

STDERR

172       The standard error shall be used only for diagnostic messages.
173

OUTPUT FILES

175       None.
176

EXTENDED DESCRIPTION

178       None.
179

EXIT STATUS

181       The following exit values shall be returned:
182
183        0     All input files were processed successfully.
184
185       >0     No output device was available, or an error occurred.
186
187

CONSEQUENCES OF ERRORS

189       Default.
190
191       The following sections are informative.
192

APPLICATION USAGE

194       The pr and fold utilities can be used to achieve reasonable  formatting
195       for the implementation's default page size.
196
197       A conforming application can use one of the file operands only with the
198       -c option or if the file is publicly  readable  and  guaranteed  to  be
199       available at the time of printing. This is because IEEE Std 1003.1-2001
200       gives the implementation the freedom to queue up the request for print‐
201       ing at some later time by a different process that might not be able to
202       access the file.
203

EXAMPLES

205        1. To print file file:
206
207
208           lp -c file
209
210        2. To print multiple files with headers:
211
212
213           pr file1 file2 | lp
214

RATIONALE

216       The lp utility was designed to be a basic version of a utility that  is
217       already  available  in  many  historical  implementations. The standard
218       developers considered that it should be implementable simply as:
219
220
221              cat "$@" > /dev/lp
222
223       after appropriate processing of options, if that is how the implementa‐
224       tion  chose  to do it and if exclusive access could be granted (so that
225       two users did not write to the device simultaneously).  Although in the
226       future  the  standard developers may add other options to this utility,
227       it should always be able to execute with no  options  or  operands  and
228       send the standard input to an unspecified output device.
229
230       This volume of IEEE Std 1003.1-2001 makes no representations concerning
231       the format of the printed output, except that it must  be  "human-read‐
232       able"  and  "non-volatile".  Thus, writing by default to a disk or tape
233       drive or a display terminal would not qualify. (Such  destinations  are
234       not prohibited when -d dest, LPDEST,  or PRINTER are used, however.)
235
236       This  volume  of IEEE Std 1003.1-2001 is worded such that a "print job"
237       consisting of multiple input files, possibly  in  multiple  copies,  is
238       guaranteed  to  print  so  that  any  one  file  is not intermixed with
239       another, but there is no statement that all the files or copies have to
240       print out together.
241
242       The -c option may imply a spooling operation, but this is not required.
243       The utility can be implemented to wait until the printer is  ready  and
244       then wait until it is finished. Because of that, there is no attempt to
245       define a queuing mechanism (priorities, classes of output, and so on).
246
247       On some historical systems, the request ID reported on the  STDOUT  can
248       be used to later cancel or find the status of a request using utilities
249       not defined in this volume of IEEE Std 1003.1-2001.
250
251       Although the historical System V lp and BSD lpr utilities have provided
252       similar  functionality,  they  used different names for the environment
253       variable specifying the destination printer.  Since  the  name  of  the
254       utility  here is lp, LPDEST (used by the System V lp utility) was given
255       precedence over PRINTER (used by the BSD lpr utility).  Since  environ‐
256       ments  of  users  frequently contain one or the other environment vari‐
257       able, the lp utility is required to recognize both.  If  this  was  not
258       done,  many applications would send output to unexpected output devices
259       when users moved from system to system.
260
261       Some have commented that lp has far too little functionality to make it
262       worthwhile.  Requests  have  proposed additional options or operands or
263       both that added functionality. The requests included:
264
265        * Wording requiring the output to be "hardcopy"
266
267        * A requirement for multiple printers
268
269        * Options for supporting various page-description languages
270
271       Given that a compliant system is not required to even have  a  printer,
272       placing  further  restrictions  upon the behavior of the printer is not
273       useful. Since hardcopy format is so application-dependent, it is diffi‐
274       cult, if not impossible, to select a reasonable subset of functionality
275       that should be required on all compliant systems.
276
277       The term unspecified is used in this section in lieu of implementation-
278       defined as most known implementations would not be able to make defini‐
279       tive statements in their conformance documents; the existence and usage
280       of  printers  is very dependent on how the system administrator config‐
281       ures each individual system.
282
283       Since the default destination, device  type,  queuing  mechanisms,  and
284       acceptable  forms  of  input  are all unspecified, usage guidelines for
285       what a conforming application can do are as follows:
286
287        * Use the command in a pipeline, or with -c, so that there are no per‐
288          mission problems and the files can be safely deleted or modified.
289
290        * Limit  output to text files of reasonable line lengths and printable
291          characters and include no  device-specific  formatting  information,
292          such  as a page description language. The meaning of "reasonable" in
293          this context can only be  answered  as  a  quality-of-implementation
294          issue,  but  it should be apparent from historical usage patterns in
295          the industry and the locale. The pr and fold utilities can  be  used
296          to  achieve  reasonable  formatting for the default page size of the
297          implementation.
298
299       Alternatively, the application can arrange its installation in  such  a
300       way  that  it  requires the system administrator or operator to provide
301       the appropriate information on lp options and environment variable val‐
302       ues.
303
304       At    a    minimum,   having   this   utility   in   this   volume   of
305       IEEE Std 1003.1-2001 tells the industry  that  conforming  applications
306       require  a  means  to print output and provides at least a command name
307       and LPDEST routing mechanism that can be used for  discussions  between
308       vendors,  application  writers,  and users.  The use of "should" in the
309       DESCRIPTION of lp clearly shows the intent of the standard  developers,
310       even  if  they  cannot  mandate that all systems (such as laptops) have
311       printers.
312
313       This volume of IEEE Std 1003.1-2001 does not specify what the ownership
314       of  the  process performing the writing to the output device may be. If
315       -c is not used, it is unspecified whether the  process  performing  the
316       writing  to  the output device has permission to read file if there are
317       any restrictions in place on who  may  read  file  until  after  it  is
318       printed.   Also, if -c is not used, the results of deleting file before
319       it is printed are unspecified.
320

FUTURE DIRECTIONS

322       None.
323

SEE ALSO

325       mailx
326
328       Portions of this text are reprinted and reproduced in  electronic  form
329       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
330       -- Portable Operating System Interface (POSIX),  The  Open  Group  Base
331       Specifications  Issue  6,  Copyright  (C) 2001-2003 by the Institute of
332       Electrical and Electronics Engineers, Inc and The Open  Group.  In  the
333       event of any discrepancy between this version and the original IEEE and
334       The Open Group Standard, the original IEEE and The Open Group  Standard
335       is  the  referee document. The original Standard can be obtained online
336       at http://www.opengroup.org/unix/online.html .
337
338
339
340IEEE/The Open Group                  2003                               LP(1P)
Impressum