lpr

What it does

lpr ("line printer") submits a file to the print spooler so it can be sent to a printer, either the system default or one specified with -P. It's a holdover from classic Unix's line-printer subsystem, and on modern systems it's implemented as a command-line front end to CUPS (Common Unix Printing System). It's largely superseded by GUI print dialogs for everyday use, but remains relevant for scripted or headless printing.

Beginner examples

• lpr file.txt — print a file to the default printer
• lpr -P office_laser file.txt — print to a specific named printer
• lpq — check what's currently in the print queue
• lprm 42 — cancel a specific queued job by its job number

lpr -P office_laser monthly_report.pdf

Advanced examples

• Print multiple copies of a document: lpr -#5 flyer.pdf
• Request duplex (two-sided) printing via a CUPS option: lpr -o sides=two-sided-long-edge document.pdf
• Print and then delete the source file automatically: lpr -r tempfile.txt
• Pipe generated output directly to the printer without an intermediate file: report_gen.sh | lpr -P label_printer
• List available printers before choosing a target: lpstat -p then lpr -P <name> file

generate_invoice.sh customer123 | lpr -P office_laser -#2

Common mistakes

• Assuming lpr prints immediately — it actually spools the job into a queue managed by CUPS, so printer availability, driver issues, or a paused queue can delay or block output silently.
• Forgetting to check lpq when a print job seems to have vanished; it may still be queued or stuck due to a printer error.
• Using lpr on a system with no printer or CUPS configured and getting a confusing "no default destination" error rather than a clear "no printer" message.
• Not specifying -P and being surprised the job went to the wrong (default) printer in a multi-printer environment.

Tips

• Combine lpr with lpq and lprm — the classic BSD print trio — for a complete command-line printing workflow: submit, inspect, cancel.
• Use lpstat -p -d to see all configured printers and which one is currently the default before submitting a job.
• For repeated formatted output (like batch invoices or labels), scripting lpr is often more reliable than manual GUI printing.

Best practices

• In scripts that print automatically, always specify -P explicitly rather than relying on whatever the system default happens to be, to avoid jobs going to the wrong printer.
• Check lpq after submitting time-sensitive print jobs to confirm they were accepted rather than assuming success.
• Prefer generating a well-formed PDF or PostScript file before printing complex layouts, since lpr's raw-mode formatting (-l) is fragile for anything beyond plain text.

Real-world use cases

• A server-side script that generates PDF invoices and pipes them straight to a label or office printer with lpr -P.
• Batch-printing shipping labels from a fulfillment script running on a headless Linux box.
• Legacy Unix administration workflows where reports are still routed to a printer via lpr as part of an automated job.

Common interview questions

• What does lpr actually do under the hood on a modern Linux system? It submits the file to CUPS's print queue rather than talking to the printer directly; CUPS handles driver translation and delivery.
• How do you cancel a print job you just submitted? Find its job number with lpq, then run lprm <job number> (or lprm - to cancel all of your own jobs).
• Why might a lpr command "succeed" but nothing prints? The job is queued, not necessarily printed instantly — the queue could be paused, the printer offline, or a driver mismatched; checking lpq and lpstat reveals the actual state.