Detailed command line options

Let's take a closer look at the Arguments field in the filter setup. Going back to our a2ps example:

Here we use %s to represent the full path of the print job you are processing after RPM has written it to the working directory.

The RPM filter action supports other command-line arguments. You can use any or all of these.

Please note that for any given job, some of these fields may be blank. If the data is empty, then RPM will not make the substitution, which could leave you with something interesting on your command line. Hopefully, that won't cause a problem.

Here are all the command line arguments available:

%s  full path to the file to be processed 
%f  filename to process minus the path 
%n  name of source file 
%j  job name from control file 
%t  title from control file 
%b  banner from control file 
%c  class from control file 
%h  hostname specified by the lpr client 
%u  user specified in the control file 
%i  RPM job ID
%m  mail field from control file 
%S  RPM queue sequence number 
%C  control file name and path 
%q  RPM queue name

Note that the %h and %u fields come from the LPR protocol. RPM merely reports them, but the protocol requires them.

RPM creates the job ID seen in %i and should always be unique.

The queue sequence number seen in %S represents the number of jobs received by that queue. You can reset this sequence number in the user interface by right-clicking on a queue name. If you reset, then the next filter action that runs will use one for the queue sequence number.

The control file name and path in %C are determined by RPM when it creates the print job.

The queue name in %q is set by the LPR protocol when RPM receives the job; we also require a queue name for telnet protocol jobs.

Any other fields, such as the job, title, banner, or class, can be blank for a given job. You would control these values from the sending program, although you can set them in RPM Elite using the data extraction transform.

Note that RPM looks at the actual data value for these potentially optional fields, and only attempts to update the command line with these values if the job includes those values.

For that reason, you should probably not specify some of the less likely fields, like the indent value, unless you are confident your print client is providing those values, or you are setting them with the data extraction transform.