I've given your script a try, but the result was rather bad. It ate all my memory and half hung the system. I was also running a kernel compile at the time which may have contributed, but that still does not explain. Eventually I was able to break out of it, but only with some difficulty: $ ./usbd.awk sh: /sys/bus/usb/devices/usb1: is a directory ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^Cbash: [5623: 2] tcsetattr: Interrupted system call $ I've answered a couple of your questions below. On Monday 20 July 2009, Steve Calfee wrote: > 3) I don't have a multiple configuration device for test, but It > doesn't look like sysfs maintains the information about multiple > configs, which would be nice to display. This is a known limitation relative to the devices file in usbfs or debugfs. > 6) I hate the format of the output, Weird contractions confusing to > humans, apparently the format arranged for scripts to grab things at > fixed offsets in the string. I agree completely and it was discussed a bit in the thread. For the usb-devices script the goal was maximum compatibility with the existing devices file, so I kept all the ugliness and inconsistencies in the format of that file. > I was not trying to make it faster, but the awk script is about 4 > times faster than the bash script: > "time usb-devices >/dev/null; time usbd.awk >/dev/null" Almost any language is bound to be faster than shell script, but I would personally pick perl rather than awk as the more logical replacement. Question is if speed is that much of an issue as the script is not really intended to be used in any hot paths. The requirement of bash already makes it unsuitable for use in initrds (and so would perl, and possibly gawk), although I suspect busybox' shell would run the script correctly (provided the shebang is changed to '#! /bin/sh'). Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html