parser problem

parser problem

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Trying to anticipate the udev crippling, this one seems like a bug:

  BUS="scsi", SYSFS{model}="FLASH G13", KERNEL="sd?1", NAME="%k", SYMLINK="flash", GROUP="flash", MODE="0660"

(all in one line) works.
Both of the following:

  BUS="scsi", SYSFS{model}="FLASH G13", KERNEL="sd?1",
    NAME="%k", SYMLINK="flash", GROUP="flash", MODE="0660"

  BUS="scsi", SYSFS{model}="FLASH G13", KERNEL="sd?1", \
    NAME="%k", SYMLINK="flash", GROUP="flash", MODE="0660"

yield *all* "FLASH G13" scsi devices to be chgrp'd to flash and
chmod'd to 660. Seems like the newline causes udev to ignore the
previous match specification.

Parser bug?

If I could find a specification about the rules syntax, I might be
able to find my own errors. Any pointers?

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
kermit: why are there so many songs about rainbows?
fozzy: that's part of what rainbows do.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: parser problem

[Kay Sievers]

On Tue, 2004-12-21 at 15:17 +0100, martin f krafft wrote:
> Trying to anticipate the udev crippling

The answer to this email is delayed for the next 72 hours!

> this one seems like a bug:
> 
>   BUS="scsi", SYSFS{model}="FLASH G13", KERNEL="sd?1", NAME="%k", SYMLINK="flash", GROUP="flash", MODE="0660"
> 
> (all in one line) works.
> Both of the following:
> 
>   BUS="scsi", SYSFS{model}="FLASH G13", KERNEL="sd?1",
>     NAME="%k", SYMLINK="flash", GROUP="flash", MODE="0660"
> 
>   BUS="scsi", SYSFS{model}="FLASH G13", KERNEL="sd?1", \
>     NAME="%k", SYMLINK="flash", GROUP="flash", MODE="0660"
> 
> yield *all* "FLASH G13" scsi devices to be chgrp'd to flash and
> chmod'd to 660. Seems like the newline causes udev to ignore the
> previous match specification.
> 
> Parser bug?
> 
> If I could find a specification about the rules syntax, I might be
> able to find my own errors. Any pointers?
> 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: parser problem

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

also sprach martin f krafft <madduck@madduck.net> [2004.12.21.1517 +0100]:
> chmod'd to 660. Seems like the newline causes udev to ignore the
> previous match specification.

So noticing the recent announcement where multiline is a feature
request, I tried to figure out why I thought that it can be
multiline in the first place. My first guess was because of the
commas, which seem to be syntactic sugar without a real purpose.

My second guess comes from Lindsay saying:

  "I see no problem with having owner, group and mode spec"d in udev
  rules files. Certainly this furthers the the purpose of
  centralization. The syntax of the file is reasonably forgiving,
  and anyone wanting a greater degree of order could format it to
  personal taste so as to make it more readable."

More readable to me is <80 columns.

Oh well, apparently we now have to define permissions policy in
column 190. Yeah udev!

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
"never speak disrespectfully of society.
 only people who can't get into it do that."
                                                        -- oscar wilde

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: parser problem

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.21.1534 +0100]:
> > Trying to anticipate the udev crippling
> 
> The answer to this email is delayed for the next 72 hours!

I'll read that as an admission of guilt. If only you would have had
the time/courage/courtesy to provide an actual reason for the
permissions.d removal...

Don't bother replying at all. In 72 hours I'll be far away from
a computer anyway.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
"reife des mannes, das ist es,
 den ernst wiedergefunden zu haben, den
 man hatte als kind beim spiel."
                                                -- friedrich nietzsche

"america may be unique in being a country which has leapt
 from barbarism to decadence without touching civilization."
                                                        -- john o'hara

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: parser problem

[Greg KH]

On Tue, Dec 21, 2004 at 03:50:38PM +0100, martin f krafft wrote:
> also sprach martin f krafft <madduck@madduck.net> [2004.12.21.1517 +0100]:
> > chmod'd to 660. Seems like the newline causes udev to ignore the
> > previous match specification.
> 
> So noticing the recent announcement where multiline is a feature
> request, I tried to figure out why I thought that it can be
> multiline in the first place. My first guess was because of the
> commas, which seem to be syntactic sugar without a real purpose.

The commas define the different fields in a line.  All udev rules are
single line, that is why people have recently asked for longer ones.

> More readable to me is <80 columns.
> 
> Oh well, apparently we now have to define permissions policy in
> column 190. Yeah udev!

Um, Kay just provided a patch to allow longer lines.  What's the problem
with that?

And hey, what's wrong with 190 column lines, just use a tiny font :)

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel