lprm(1) lprm(1)NAME lprm - remove jobs from the line printer spooling queue for a Berkeley file system (4.2) SYNOPSIS lprm [ -Pprinter ] [-] [jobno]... [user]... DESCRIPTION lprm removes a job, or jobs, from a printer spool queue. Since the spooling directory is protected from users, using lprm is normally the only method by which a user may remove a job. lprm without any arguments deletes the currently active job if it is owned by the user who invoked lprm. Specifying a user's name or list of users' names causes lprm to attempt to remove any queued jobs belonging to that user (or users). This form of invoking lprm is useful only to the super-user. A user may remove an individual job from a queue by specify- ing its job number. This number may be obtained from the lpq(1) program, for example, % lpq -l ken : 1st [job 013ucbarpa] (standard input) 100 bytes % lprm 13 lprm announces the names of any files it removes and is silent if there are no jobs in the queue that match the re- quest list. lprm kills off an active daemon, if necessary, before remov- ing any spooling files. If a daemon is killed, a new one is automatically restarted upon completion of file removals. FLAG OPTIONS The following flag options are interpreted by lprm: -Pprinter Specifies the queue associated with a specific printer, otherwise the default printer, or the value of the PRINTER variable in the environment is used. - Removes all jobs that a user owns. If the superuser employs this flag, the spool queue is emptied entirely. The owner is determined by the user's login name and host name on the machine where the lpr command was in- voked. April, 1990 1
lprm(1) lprm(1)FILES /etc/printcap Printer characteristics file /usr/spool/* Spooling directories /usr/spool/*/lock Lock file used to obtain the process ID of the current daemon and the job number of the currently active job SEE ALSO lpd(1M), lpr(1), lpq(1). DIAGNOSTICS A ``Permission denied'' is received if the user tries to re- move files other than his own. BUGS Since there are race conditions possible in the update of the lock file, the currently active job may be incorrectly identified. 2 April, 1990