./_Man_NeXT_html/html1/lprm.1.html

Manual page for LPRM(1)

lprm - remove jobs from the line printer spooling queue

SYNOPSIS

lprm [ -Pprinter ] [ - ] [ job # ... ] [ user ... ]

DESCRIPTION

The lprm utility will remove a job, or jobs, from a printer's 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.

Issuing lprm without any arguments will delete the currently active job if it is owned by the user who invoked lprm.

If the - flag is specified, lprm will remove all jobs a user owns. If the super-user employs this flag, the spool queue will be emptied entirely. The owner is determined by the user's login name and host name on the machine where the lpr command was invoked.

Specifying a user's name, or list of user names, will cause lprm to attempt to remove any jobs queued belonging to that user (or users). This form of invoking lprm is useful only to the super-user.

A user may dequeue an individual job by specifying its job number. This number may be obtained from the lpq.1 program, e.g.

% lpq -l

1st: ken	[job #013ucbarpa]
	(standard input)	100 bytes
% lprm 13

The lprm utility will announce the names of any files it removes, and is silent if there are no jobs in the queue that match the request list.

The lprm utility will kill off an active daemon, if necessary, before removing any spooling files. If a daemon is killed, a new one is automatically restarted upon completion of file removals.

The -P option may be used to specify the queue associated with a specific printer (otherwise the default printer is used. Note that the printer cannot be specified using the PRINTER environment variable.)

FILES

/etc/printcap	printer characteristics file - if NetInfo is not running
/usr/spool/*	spooling directories
/usr/spool/*/lock	lock file used to obtain the pid of the current
	daemon and the job number of the currently active job

DIAGNOSTICS

``Permission denied'' if the user tries to remove 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.