Oops, did that patch in reverse. There is more than one occorunce of this bug, so here is the updated patch. Mitch -------- Original Message -------- Subject: Parse error in reading /etc/udev/udev.rules [udev-009] Date: Tue, 23 Dec 2003 12:13:31 +0000 From: Mitch To: linux-hotplug-devel@lists.sourceforge.net Hi, I've been pulling my hair out why my rule in udev.rules wasn't being honoured. I turned debugging on and didn't get any joy either. Perusing the source i found that DEBUG_PARSER is *not* defined when i compile DEBUG=true ! This provides very useful information. Please enable it. Anyhow back to my problem. I found i was getting a parse error in udev.rules with the stock default provided udev.rules and hence no additional lines were being read and parsing terminates - note this parse is *silent* and the user is given no feedback if the parser fails. It would be nice even with debug turned off that we got feedback about parse errors ! Dec 23 11:49:29 core udev[13191]: namedev_init_rules: read ' ' Dec 23 11:49:29 core udev[13191]: namedev_init_rules: unknown type of method '' Dec 23 11:49:29 core udev[13187]: namedev_init_rules: /etc/udev/udev.rules:14:1073743040:< >: field missing or parse error So i looked at the source, and found that i need to make the change shown in the attachment since fgets() *stores* the '\n' character in the buffer and so the empty line test fails and parsing stops. With this fix in the file is parsed correctly and my rules are honoured. Please apply. Cheers Mitch P.s. man fgets() shows: fgets() reads in at most one less than size characters from stream and stores them into the buffer pointed to by s. Reading stops after an EOF or a newline. If a newline is read, it is stored into the buffer. A '\0' is stored after the last character in the buffer.