On 02/24/2012 10:27 AM, Ondrej Vasik wrote: > Leading = probably makes sense, however the request in > https://bugzilla.redhat.com/show_bug.cgi?id=691466 was talking about > support for octal digits only
The original request was that "chmod 0755 dir" should clear the setuid bits. We're not satisfying that exact request; we're merely trying to find a way to satisfy the intent of the request, which as I understand it is the need in shell scripts to use an octal mode to specify all the permissions bits of a directory. > (and leading = seems to me like a hybrid > mode - which would make the required changes in legacy scripts for > compatibility with old chmod even harder) Sorry, I don't follow -- either way, legacy scripts would need to be changed. It's no harder in a script to prepend a leading '=' than to prepend a leading '0'. And the advantage of '=' is that it's clearer to everybody that a GNU extension is being used; also, '=' avoids the tricky business about five-or-more digits, which is confusing. If '=' is confusing because it's used in symbolic modes, we can choose some otherwise-unused character, such as '@'. > and would definitely mean > some changes to gnulib's mode_compile(). No matter what notation we adopt, the change should be in mode_compile, not in chmod.c. Otherwise, "mkdir -m MODE DIR" will behave differently from "chmod MODE DIR", and that'll add confusion. I hope the change can be limited to mode_compile, to mode_adjust, and to the user documentation. chmod.c shouldn't need any changes (nor should mkdir.c). > But mode_compile() still computes the correct mode from the octal > digits, mode_adjust() cleans the setgid/setuid bits from it (based on > the dir boolean). Yes, and the point is that these properties would still be true if we limited the code changes to mode_compile and mode_adjust.
