Add --wait option to socranop-ctl

[lack]

The default behavior is now to exit (with error code) if no device exists.

[ndim]

Uhm... is that now the same behaviour with or without --no-dbus?

[lack]

No, it only waits in dbus mode... Do you think that's important?

[ndim]

No, it only waits in dbus mode... Do you think that's important?

Neither the socranop-ctl --help output nor the man page qualify the description of --wait with "only works without --no-dbus given".

[ndim]

Personally, I find it surprising that the CLI supports waiting for a device to be connected. My standard expectation would be "no device connected? tell me, and exit.".

Command line programs are usually of the type which is launched, does its task, and then exits.

Waiting for a device to be connected I would only expect from a GUI, because GUI programs are designed to keep running eternally, and thus need to react to events happening during that eternity.

[ndim]

[user@host socranop]$ socranop-session-service 
No recognised device was found
Waiting for one to arrive...
Traceback (most recent call last):
  File "/home/ndim/proj/socratools/socranop/socranop/dbus.py", line 196, in uevent
    idProduct = int(device.get_property("ID_PRODUCT_ID"), 16)
TypeError: int() can't convert non-string with explicit base
[user@host socranop]$ 

This happens upon plugging in the device.

[ndim]

More information with the new debug output from socranop-session-service:

Device added (idVendor='05fc', idProduct=None)
Traceback (most recent call last):
  File "/home/ndim/proj/socratools/socranop/socranop/dbus.py", line 201, in uevent
    idProduct = int(idPStr, 16)
TypeError: int() can't convert non-string with explicit base

Why does GUdev give us a device without an idProduct string?

[lack]

Weird - That "wait for the device" thing used to work. Honestly, it's not important to the CLI, but I'd like to fix it. Maybe to unblock 0.5 I'll just remove it for now, and add an issue to fix it.

[grawity]

Copying from IRC:

The explanation is that udev properties are not the same thing as sysfs attributes, so "idFoo" in sysfs does not automatically correspond to "ID_FOO" in udev; all properties are generated internally by udev rules and helpers which mostly just happen to load data from /sys.

In this case the usb_id udev rule reads idVendor/idProduct from /sys and generates the ID_VENDOR_ID / ID_MODEL_ID device properties, and yes it has always been called "ID_MODEL" for as long as usb_id has existed.

GUdev does have an interface to directly access sysfs attributes, so an alternative to the above is get_sysfs_attr("idProduct"), although using properties is probably preferred.