[cups.general] Mail to User if a Printjob is abortet

[Helge Blischke]

Daniel Spannbauer wrote:

> 
> 
> Helge Blischke schrieb:
>> Johannes Meixner wrote:
>> 
>>> Hello,
>>>
>>> On May 7 11:06 Daniel Spannbauer wrote (shortened):
>>>> Under /usr/lib/cups/notifier/ there are some Binary which seem to send
>>>> the Mail. Is it posibly to write a own script for using by cups?
>>> Yes.
>>>
>>> For experimenting I added right now in subscriptions.conf
>>> -----------------------------------------------------------
>>> <Subscription 19>
>>> Events job-created job-completed job-stopped
>>> Owner jsmeix
>>> Recipient mynotifier:jsmeix at suse.de
>>> LeaseDuration 0
>>> Interval 30
>>> ExpirationTime 0
>>> NextEventId 3
>>> </Subscription>
>>> -----------------------------------------------------------
>>> and I added a new /usr/lib/cups/notifier/mynotifier
>>> with "-rwxr-xr-x  root root" permissions
>>> -----------------------------------------------------------
>>> #! /bin/bash
>>>
>>> # get debugging info in /var/log/cups/error_log:
>>> set -x
>>>
>>> cat /dev/null >/tmp/mynotifier.out
>>> echo "argv[1]: '$1'" >>/tmp/mynotifier.out
>>> echo "argv[2]: '$2'" >>/tmp/mynotifier.out
>>> echo "argv[3]: '$3'" >>/tmp/mynotifier.out
>>> echo "argv[4]: '$4'" >>/tmp/mynotifier.out
>>> echo "argv[5]: '$5'" >>/tmp/mynotifier.out
>>> echo "argv[6]: '$6'" >>/tmp/mynotifier.out
>>> set >>/tmp/mynotifier.out
>>>
>>> cat - >/tmp/mynotifier.stdin
>>>
>>> exit 0
>>> -----------------------------------------------------------
>>>
>>> Unfortunately (at least not with my CUPS 1.3.9)
>>> a notifier does not get the command line parameters
>>> and environment variables like usual CUPS filters
>>> (compare "man 7 filter") so that adding a real working
>>> notifier as a bash script seems to be complicated.
>>>
>>> Instead a notifier gets the data in a special format via stdin
>>> where I currently only find the print queue URI but I can
>>> neither find the job owner nor the job id.
>>>
>>> I don't know a documentation where this format is described.
>>> Perhaps you must view the sources in the notifier/ directory.
>>>
>>>
>>> Kind Regards
>>> Johannes Meixner
>> 
>> With CUPS 1.3.5, I experimentally used a Perl script as a notifier which
>> in turn calls the testnotify utility (which gets built if you compile
>> CUPS from the sources). Ths test utility proviedes a lot of information
>> about the current event (like job attivutes etc.) and, of course, the
>> reason for aborting.
>> 
> 
> Hello Helge,
> 
> I have the testnotiy. Is there any documentation for it? How to use it?
> 
> Regards
> 
> Daniel
> 
> 
> 
>> Helge
>> 
>> _______________________________________________
>> cups mailing list
>> cups at easysw.com
>> http://lists.easysw.com/mailman/listinfo/cups
> 

Hello Daniel,

I don't know of any documentation. By looking into the source and by
experiment I found out the following:

*   If the first command line argument for this utility is
    testnotify://nowait
    then the program exits immediately after logging the current
    notify event (otherwise it waits for the next event to occur).

*  for the current (or each, see above) event it logs the complete
   notify eventto standard error.

I'd suggest to configure the subcriptions.conf to use the testnotify
utility and either grabbing the information from the cups error_log
or encapsulating testnotify with a little script which dumps the
standard error to a temporary file.

Helge

PS: as mentioned in my previous post, my experience with this 
was with CUPS 1.3.5. The reason for this hack was that in that
version the official mailto notifier seemed not to work as requested;
maybe this has been improved meanwhile.