Job NOT being filtered

Kurt Pfeifle kurt.pfeifle at infotec.com
Fri May 25 04:52:34 PDT 2007


> > > > Stefan Adams wrote:
> > > > >>Stefan Adams wrote:
> > > > >>
> > > > >>>It's possible to filter a job of text sent from the command line, right?
> > > > >>>
> > > > >>>Like this:
> > > > >>>
> > > > >>># echo hi | lpr
> > > > >>>
> > > > >>># cat /etc/cups/*.{types,convs}
> > > > >>>text/hi         printable(0,1024) + string(0,hi)
> > > > >>>text/hi              application/vnd.cups-postscript    3       skeleton
> > > > >>>
> > > > >>># ls -l /usr/lib/cups/filter/skeleton
> > > > >>>-rwxr-xr-x  1 root root 3522 May 22 20:01 /usr/lib/cups/filter/skeleton*
> > > > >>>
> > > > >>># cat /usr/lib/cups/filter/skeleton
> > > > >>>#!/usr/bin/perl
> > > > >>>$|=1;
> > > > >>>open TMP, ">/tmp/skeleton.tmp";
> > > > >>>print TMP qx{date};
> > > > >>>close TMP;
> > > > >>>exit 0;
> > > > >>>[...]
> > > > >>
> > > > >>What springs to my eyes at the first glance is that your
> > > > >>filter does not follow the filter calling conventions.
> > > > >
> > > > >
> > > > > Filter calling conventions?  Please explain?
> > > > >
> > > > > I've removed out every piece possible to make this as simple as possible.  I've started with Andreas Bohne-Lang's Cups Filter/Backend NOP and could not get it to work.  I've tried and tried again and have reduced it all to the most simple stuff I can think of.  At this point, I don't even care if it prints, the problem is that the filter is not being executed at all.
> > > > >
> > > > > I've even tried in my .convs file:
> > > > >
> > > > > */*     application/vnd.cups-postscript    3       skeleton
> > > > >
> > > > > But skeleton will not get run!
> > > > >
> > > > >
> > > > >>Helge
> > > > >>
> > > > >>
> > > > >>--
> > > >
> > > > A CUPS compatible filter needs to accept the following command line
> > > > options (in this order):
> > > > 	job-id		(an integer)
> > > > 	username
> > > > 	job-title
> > > > 	number-of-copies (an integer)
> > > > 	job-options	(a string containing the options separated by white space)
> > > > 	file-to-print	(this is optional, if not provieded, the filter needs
> > > > 			to read from STDIN).
> > > > The filter's output *MUST* go to STDOUT.
> > >
> > > But the filter would still be called, even if it didn't behave properly.  That's why the only commands I have in there are to open a file and stamp the date -- which has NEVER happened as a reult of printing.  Even tho I don't send the output to STDOUT, the filter should still be called and the date stamped to a tmp file.
> > >
> > > Or am I fully mistaken?
> > >
> > > > And, when introducing a new filter, you need to restart CUPS
> > > > (or at least issue a kill -HUP pidof(cupsd) to force a
> > > > reload).
> > >
> > > /etc/init.d/cups restart EVERY time.
> > >
> > > > For further details, see the documentation (which came with your
> > > > distribution, or read the documentation at www.cup.org)
> > >
> > > Read the docs online, read the CUPS book published by SAMS, read thru forums, read the install instructions for every filter I could find...  They all say the same thing: in a nutshell, do what I did above.  But under no circumstance is the filter being called.  Even when using Andreas' Log and Quota script out of the box, it still never got executed.
> > >
> > > I was running CUPS 1.1.23 and have since upgraded to CUPS 1.2.11 with no different results.
> > >
> >
> > Hi Stefan.
> >
> > I've duplicated your effort and found that it ran skeleton as you have
> > coded it:
> >
> >
> > # grep -i skeleton error_log
> > d [23/May/2007:10:47:10 -0500] start_job: filter="/opt/TWWfsw/cups124/lib/filter
> > /skeleton"
> > d [23/May/2007:10:47:10 -0500] cupsdStartProcess("/opt/TWWfsw/cups124/lib/filter
> > /skeleton", 0x8fc9930, 0xbfe542a0, -1, -1, 11)
> > I [23/May/2007:10:47:10 -0500] Started filter /opt/TWWfsw/cups124/lib/filter/ske
> > leton (PID 24738) for job 36.
> > D [23/May/2007:10:47:10 -0500] PID 24738 (/opt/TWWfsw/cups124/lib/filter/skeleto
> > n) exited with no errors.
> >
> > # cat /tmp/skeleton.tmp
> > Wed May 23 10:47:10 CDT 2007
> >
> > # grep "text/hi" mime*
> > mime.convs:text/hi                 application/vnd.cups-postscript 3       skele
> > ton
> > mime.types:text/hi               printable(0,1024) + string(0,hi)
> >
> >
> > # cat skeleton
> > #!/usr/bin/perl
> > $|=1;
> > open TMP, ">/tmp/skeleton.tmp";
> > print TMP qx{date};
> > close TMP;
> > exit 0;
> >
> >
> > The only difference between your CUPS install and mine is that I'm
> > currently running CUPS 1.2.4. Sorry, I couldn't be of anymore help.
> >
> > Good luck.
> >
> > Angle
>
> Angle,
>
> I really appreciate you duplicating my test at your location!  Thanks also for the log snippet.  It's great to be able to see what's going on with filters!  That really helps!!


Please do also read "man filter" (and "man backend"). It also helps  :-)

In short: there is a calling convention for CUPS filters, and your filter *must* conform to that calling convention. It looks like this:

  filter job user title num-copies options [ filename ]

A filter must be able to process 5 or 6 arguments (if the 6th is missing, it must expect its input from stdin). The first 5 arguments must be in that order. ("Process" the arguments may even mean to ignore them completely; but expect the input for your filter to be handed down from the previous filter in the chain as either a filename (which then is the 6th argument), or via stdin).


> So strange that mine just will NOT do it...

No, it is a result to be expected if your filter does not conform to the (documented) CUPS filter requirements.   :-)

Cheers,
Kurt




More information about the cups mailing list