Philipp Marek wrote: > XOR would allow for negation. I think this will make it even more convoluted. The 'not' bit can be easily expressed with a regular/take pattern. XOR will require a new paradigm.
>> Then sample rules (very pseudocode) would be: >> >> Match everything without a world readable bit: >> match 0000 / 0004 >> not match 0004 / 0004 alternatively > So, if I understand you, there's a mask (for AND) and a pattern for CMP. Yes. >> Match suid stuff not marked as executable by user: >> match 4000 / mask 4100 > So, in C notation, > if ( (mode AND 04100) == 04000 ) > right? Yes. >> Exclude sticky stuff non-executable by others and non writable by the group >> not match 1000 / mask 1021 > How would I match a file that has *none* of others-rwx set? ie. match > (mode & 0007) == 0 Precisely - you mask off (& 1) the stuff you are interested in and compare it to an expected result (the values of the bits you are interested in) > Would your notation be a negative ignore pattern (ie. a "take" pattern) with > not match 0 / mask 0007 > and ignoring everything else? > > That sounds a bit ... convoluted, with the double negation. But I don't have > any better solution; I'll think a bit more. > It isn't that bad... it is akin to ./**some-specific-stuff** versus t./**some-specific-stuff**. Besides the match 0 is not really a negation. It is an assertion that others r w and x are off, without claiming anything about special/user/group perms. >>> And for the first version at least I'd like to stay with parsing some >>> numbers - going for "grwx" seems overkill, especially as there'll only >>> be one or two values be used in the common case, which I'd have special >>> coded as abbreviations. >> I think that whoever will want to power-use this, will have to know >> octal logic anyway. Macros like 'suid', 'sticky', 'world-readable', >> 'group-writable' seem to be the way to go to make it more user friendly >> (the 'not' modifier still applying). > That's always possible. > >> I am just thinking out loud of course, someone might come up with a much >> nicer way to do this. > Possibly ... I'd like to avoid coding something if I'm not sure that it makes > sense and is backwards compatible (if we find that we need some extension). > > > Thank you for the idea ... I'll sleep over that. > No problem. Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
