backend(7)
β¨ backend(7) β the OpenPrinting glow-up edition β¨
okay bestie, sit down, hydrate, because today we're learning about backends in the backend(7) manual. this is the OpenPrinting era of CUPS and honestly? it's giving plumbing but make it fashion. π
π NAME π
backend β cups backend transmission interfaces. that's it, that's the name, no notes. π
π¦ SYNOPSIS π¦
backend
backend job user title num-copies options [ filename ]
#include <cups/cups.h>
const char *cupsBackendDeviceURI(char **argv);
void cupsBackendReport(const char *device_scheme,
const char *device_uri,
const char *device_make_and_model,
const char *device_info,
const char *device_id,
const char *device_location);
ssize_t cupsBackChannelWrite(const char *buffer,
size_t bytes, double timeout);
int cupsSideChannelRead(cups_sc_command_t *command,
cups_sc_status_t *status, char *data,
int *datalen, double timeout);
int cupsSideChannelWrite(cups_sc_command_t command,
cups_sc_status_t status, const char *data,
int datalen, double timeout);
copy that character for character, no cap. β¨
πΈ DESCRIPTION πΈ
so. backends are a special type of filter(7) whose whole job is sending print data to devices on the system and discovering different devices. main character energy, truly. π
like filters, backends have to be able to read from a filename given on the command line or from standard input β and they copy standard input to a temporary file whenever the physical interface needs it. π«Ά
the command name (argv[0]) is set to the device URI of the destination printer. important: authentication info inside argv[0] gets removed, so backend devs are urged to use the DEVICE_URI environment variable whenever auth info is required. use cupsBackendDeviceURI() to retrieve the correct device URI. π
back-channel data coming from the device should be relayed to the job filters using the cupsBackChannelWrite function. π₯
backends are also responsible for reading side-channel requests with cupsSideChannelRead() and responding with cupsSideChannelWrite(). and the CUPS_SC_FD constant defines the file descriptor you should be monitoring for incoming requests. iykyk. β
π DEVICE DISCOVERY π
when run with no arguments, the backend should list the devices and schemes it supports or is advertising, straight to standard output. the output is zero or more lines, and each line is one of these forms:
device-class scheme "Unknown" "device-info"
device-class device-uri "device-make-and-model" "device-info"
device-class device-uri "device-make-and-model" "device-info" "device-id"
device-class device-uri "device-make-and-model" "device-info" "device-id" "device-location"
the cupsBackendReport() function can generate these lines for you and handle all the necessary escaping of characters in the various strings. obsessed, honestly. π
the device-class field is one of these values:
directβ thedevice-urirefers to a specific direct-access device with no options, like a parallel, USB, or SCSI device. plug it in, it just goes. πfileβ thedevice-urirefers to a file on disk. yes, a file. we love a low-stakes device. πnetworkβ thedevice-urirefers to a networked device and conforms to the general form for network URIs. wi-fi bestie behavior. πserialβ thedevice-urirefers to a serial device with configurable baud rate and other options. and if thedevice-uricontains a baud value, that value represents the maximum baud rate supported by the device. β‘
the scheme field provides the URI scheme supported by the backend. backends should use this form only when the backend supports any URI using that scheme. the device-uri field specifies the full URI to use when communicating with the device. π¦
the device-make-and-model field specifies the make and model of the device, e.g. "Example Foojet 2000". and if the make and model is not known? you must report "Unknown". no guessing, no vibes-based labeling. periodt. π
the device-info field specifies additional information about the device β typically the make and model along with the port number or network address, e.g. "Example Foojet 2000 USB #1". πΈ
the optional device-id field specifies the IEEE-1284 device ID string for the device, which is used to select a matching driver. β¨
the optional device-location field specifies the physical location of the device, which is often used to pre-populate the printer-location attribute when adding a printer. π
π PERMISSIONS π
backends without world read and execute permissions are run as the root user. otherwise, the backend runs under an unprivileged user account β typically "lp". so like, permissions are literally the vibe check here. π
π EXIT STATUS π
here are the exit codes defined for backends. memorize them or at least screenshot this:
CUPS_BACKEND_OKβ the print file was successfully transmitted to the device or remote server. slay!! πCUPS_BACKEND_FAILEDβ the print file was not successfully transmitted to the device or remote server. the scheduler responds by canceling the job, retrying the job, or stopping the queue, depending on the state of theprinter-error-policyattribute. πCUPS_BACKEND_AUTH_REQUIREDβ the print file was not successfully transmitted because valid authentication information is required. the scheduler responds by holding the job and adding the'cups-held-for-authentication'keyword to the"job-reasons"Job Description attribute. πCUPS_BACKEND_HOLDβ the print file was not successfully transmitted because it cannot be printed at this time. the scheduler responds by holding the job. βΈοΈCUPS_BACKEND_STOPβ the print file was not successfully transmitted because it cannot be printed at this time. the scheduler responds by stopping the queue. πCUPS_BACKEND_CANCELβ the print file was not successfully transmitted because one or more attributes are not supported, or the job was canceled at the printer. the scheduler responds by canceling the job. πCUPS_BACKEND_RETRYβ the print file was not successfully transmitted because of a temporary issue. the scheduler will retry the job at a future time β and heads up, other jobs may print before this one. β³CUPS_BACKEND_RETRY_CURRENTβ the print file was not successfully transmitted because of a temporary issue. the scheduler will retry the job immediately without allowing intervening jobs. queue jump, but make it legal. π
and all other exit code values are reserved. do not go inventing your own, bestie, that's not your lane. π
π ENVIRONMENT π
on top of the environment variables listed in cups(1) and filter(7), CUPS backends can expect this one:
DEVICE_URIβ the device URI associated with the printer. π«Ά
π FILES π
/etc/cups/cups-files.conf
β NOTES β
CUPS backends are not generally designed to be run directly by the user. aside from the whole device URI situation (argv[0] and the DEVICE_URI environment variable contain the device URI), CUPS backends also expect specific environment variables and file descriptors, and they typically run in a user session that β on macOS β has additional restrictions that affect how it runs. backends can also be installed with restricted permissions (0500 or 0700), which tell the scheduler to run them as the "root" user instead of an unprivileged user (typically "lp") on the system. π³
unless you are a developer and you know what you are doing, please do not run backends directly. instead, use the lp(1) or lpr(1) programs to send print jobs, or lpinfo(8) to query for available printers using the backend. the one exception is the SNMP backend β see cups-snmp(8) for more info. β¨
π¨ NOTES π¨
CUPS printer drivers and backends are deprecated and will no longer be supported in a future feature release of CUPS. printers that do not support IPP can be supported using applications such as ippevprinter(1). yes, it's giving end of an era. plan accordingly. π
π SEE ALSO π
cups(1), cups-files.conf(5), cups-snmp(8), cupsd(8), filter(7), lp(1), lpinfo(8), lpr(1), CUPS Online Help (http://localhost:631/help)
π COPYRIGHT π
Copyright Β© 2020-2024 by OpenPrinting.
and that's the whole page, bestie!! this one came from the CUPS backend(7) man page, dated 2021-02-28, sourced from CUPS β and honestly it ate. go forth and print responsibly. π¨οΈβ¨π
π¦ where this page comes from
- alpine 3.22: cups-doc 2.4.18-r0 Β· Apache-2.0
- alpine 3.23: cups-doc 2.4.18-r0 Β· Apache-2.0
- alpine 3.24: cups-doc 2.4.19-r1 Β· Apache-2.0
- centos-stream 10: cups 1:2.4.10-18.el10 Β· Apache-2.0 WITH LLVM-exception AND BSD-3-Clause AND Zlib AND BSD-2-Clause
- debian trixie: cups-daemon 2.4.10-3+deb13u1 Β· Apache-2.0-with-GPL2-LGPL2-Exception
- debian trixie: cups-daemon 2.4.10-3+deb13u2 Β· Apache-2.0-with-GPL2-LGPL2-Exception
- fedora 43: cups 1:2.4.14-2.fc43 Β· Apache-2.0 WITH LLVM-exception AND BSD-3-Clause AND Zlib AND BSD-2-Clause
- fedora 43: cups 1:2.4.19-3.fc43 Β· Apache-2.0 WITH LLVM-exception AND BSD-3-Clause AND Zlib AND BSD-2-Clause
- fedora 44: cups 1:2.4.16-7.fc44 Β· Apache-2.0 WITH LLVM-exception AND BSD-3-Clause AND Zlib AND BSD-2-Clause
- fedora 44: cups 1:2.4.19-3.fc44 Β· Apache-2.0 WITH LLVM-exception AND BSD-3-Clause AND Zlib AND BSD-2-Clause
- nixpkgs unstable: cups 2.4.19
- opensuse-leap 16.0: cups 2.4.19-160000.2.1 Β· Apache-2.0
- opensuse-leap 16.0: cups 2.4.19-160000.2.1 Β· Apache-2.0
- opensuse-leap 16.0: cups 2.4.19-160000.2.1 Β· Apache-2.0
- opensuse-leap 16.0: cups 2.4.19-160000.2.1 Β· Apache-2.0
- ubuntu questing: cups-daemon 2.4.12-0ubuntu3
- ubuntu questing: cups-daemon 2.4.12-0ubuntu3.10
- ubuntu resolute: cups-daemon 2.4.16-1ubuntu1 Β· Apache-2.0-with-GPL2-LGPL2-Exception
- ubuntu resolute: cups-daemon 2.4.16-1ubuntu1.3 Β· Apache-2.0-with-GPL2-LGPL2-Exception
- ubuntu stonking: cups-daemon 2.4.16-1ubuntu3 Β· Apache-2.0-with-GPL2-LGPL2-Exception
- Copyright Β© 2020-2024 by OpenPrinting
- Copyright Β© 2007-2019 by Apple Inc
- Copyright Β© 1997-2006 by Easy Software Products
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms