udev-ish replacement for hal-cups-utils?
Kay Sievers
kay.sievers at vrfy.org
Tue Jul 14 04:30:15 PDT 2009
On Tue, Jul 14, 2009 at 09:24, Martin Pitt<martin.pitt at ubuntu.com> wrote:
> Hello all,
>
> Tim Waugh [2009-07-13 21:40 +0100]:
>> To recap on why this data needs to be stored: we need the device ID,
>> obtained from the device at connection time, at the point where the
>> device has already been disconnected. This is so we can match it to the
>> existing CUPS queue by constructing a device URI and comparing with
>> those of the existing queues.
>>
>> Looks like I'll need to investigate Martin's suggestion of using
>> IMPORT{program} then.
>
> I think it's much easier than that. You can exploit the fact that
> device properties ($ENV{}) are still available at a removal event
> (unlike the sysfs attributes). Try this:
>
> ------------------ 8< -----------------------
> $ cat /etc/udev/rules.d/printer.rules
> ACTION=="add", KERNEL=="lp*", ATTRS{ieee1284_id}=="?*", ENV{ID_IEEE1284}="$attr{ieee1284_id}", RUN+="/bin/sh -c 'echo add $attr{ieee1284_id} >> /tmp/printer.log'"
>
> ACTION=="remove", ENV{ID_IEEE1284}=="?*", RUN+="/bin/sh -c 'echo remove $env{ID_IEEE1284} >> /tmp/printer.log'"
> ------------------ 8< -----------------------
If it makes stuff easier, there is (since a long time) a "REMOVE_CMD"
in standard udev rules. A rule from any event can define a command to
run when the device goes away:
95-udev-late.rules:
ACTION=="remove", ENV{REMOVE_CMD}!="", RUN+="$env{REMOVE_CMD}"
Thanks,
Kay
More information about the devkit-devel
mailing list