-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Update: X was irrelevant, but 't' and 's' have been added.
Will work on ugo on the RHS when I next get a chance.
All changes have been pushed to my github.
Trevor
On 12/13/2009 08:42 PM, Trevor Vaughan wrote:
> I'm now satisfied with this patch as far as it goes.
>
> I still need to add support for the RHS equaling Xst|ugo, but the parts
> that are included are the most important.
>
> Markus was correct regarding my munge method beging...well, munged as
> well as some fallacies in my regex. Thanks for the help.
>
> I'll figure out how to submit it once I beat my head against rspec for a
> while.
>
> Trevor
>
> On 12/13/2009 09:24 AM, Trevor Vaughan wrote:
>> Markus,
>
>> Thanks for looking things over, but I have a few questions.
>
>> On 12/13/2009 01:09 AM, Markus Roberts wrote:
>>> That's an interesting patch, nicely done so far as it goes, but (by my
>>> reading at least) it needs to be rethought a little to work as
>>> expected. There are basically two problems*:
>
>>> 1) Some of the allowed modes, such as g+w are actually mode _changes_,
>>> that only specify some of the bits. There's nothing I can see to stop
>>> people from only partially specifying the mode.
>
>> This was actually part of the intent. The mode starts at 0000, but then
>> gets re-mapped if the file exists. This seems to work the way I expect
>> in preliminary testing.
>
>> The scenario that I needed was one where I honestly didn't care what
>> other group bits were set, but I needed to be sure that write was gone.
>> So, I just wanted to be able to specify g-w and leave r and x alone. I
>> also didn't know what the actual mode would be set to.
>
>> This started to come up far too often and, after experimenting with the
>> normal symbolic chmod, the patch implements the expected behavior as
>> closely as possible.
>
>
>>> 2) The value that escapes from munge isn't canonical; the same bit
>>> pattern could be represented in multiple ways.
>
>> I think I understand what you're saying here, but I don't quite follow.
>> Munge is now returning either a bit pattern or a symbolic mode string.
>> I checked the parts of the code that seemed to be checking for mode
>> synchronization and I couldn't find a difference.
>
>
>>> The second is, I suspect, the cause of the constant resetting, as the
>>> but the first is going to be just a much of a problem.
>
>> Could you perhaps provide the data flow that I'm missing? I checked
>> what I thought was the output from the in_sync? function and, while it
>> returned 'false', I couldn't figure out why.
>
>
>>> A couple of alternatives I can see:
>
>>> * Break all the bits out as separate parameters ("owner_write",
>>> "owner_read", etc.) and rework mode as a shorthand for setting them.
>>> This would arguably be the most powerful (since it gives meaning to
>>> things like o+x) but it would also be massive overkill for the common
>>> case.
>
>>> * Move the symbolic interpretation into munge and have it only accept
>>> /^([ugoa]+)=([rwx]+)$/ or (perhaps a delimited list of them), and
>>> return the value as if they's specified a number
>
>> I see what you're saying, but I'm not sure why it makes a difference.
>> Perhaps, I'm not following the full impact of munge. I'll give it a try
>> and see if it clears things up.
>
>> And, it turns out that the regex that I wanted was:
>
>> /^(([ugoa]+)([+-=])([rwx]+),?)+$/
>
>> You can specify pretty much anything separated by commas, even things
>> that make no sense and the chmod command just applies them from left to
>> right. Kind of funky, but this is legal:
>
>> chmod ugo=rwx,g-x,u=r,g-w foo
>
>> results in => -r--r--rwx foo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAksltDwACgkQyjMdFR1108AJKACgsp2RiOJn/cdApWUY08gn9VGR
zCUAnjc5Z7bMVytNOun4Owfkdrg1aIGD
=satB
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
