Re: [1003.1(2016)/Issue7+TC2 0001392]: find(1): clarify whether -perm ops - and + should follow chmod
Geoff Clare via austin-group-l at The Open Group wrote: > I think I would prefer just to require consistency with chmod in Issue 8. > The difference from chmod violates the principle of least surprise. > > Another reason to disallow ignoring the umask for '=' without a "who" > is that this makes it identical to 'a=', thus reducing the available > functionality for no reason. > > I propose: Looks good.
Re: [1003.1(2016)/Issue7+TC2 0001392]: find(1): clarify whether -perm ops - and + should follow chmod
Geoff Clare wrote, on 19 Aug 2020: > > > -- > > (0004926) geoffclare (manager) - 2020-08-19 09:22 > > https://austingroupbugs.net/view.php?id=1392#c4926 > > -- > > > I think we should issue a "standard is silent" interpretation, thus > > allowing both behaviours for Issue 7, but we should make a change in Issue > > 8 to require the BSD behaviour. > > I started looking into a wording change for this, but I'm not too > keen on where it would end up. It would have a particular difference > from chmod that would "stick out like a sore thumb", which is that > when '=' is used without a "who", find ignores the umask but chmod > uses it. > > Is that what BSD find does? Or is it consistent with chmod here > (contrary to what the standard requires)? This got answered via a bug note (4941): macOS (which uses BSD find) is consistent with chmod. > Perhaps we should allow the difference but recommend against it. I think I would prefer just to require consistency with chmod in Issue 8. The difference from chmod violates the principle of least surprise. Another reason to disallow ignoring the umask for '=' without a "who" is that this makes it identical to 'a=', thus reducing the available functionality for no reason. I propose: The mode argument is used to represent file mode bits. It shall be processed in an identical matter to the symbolic_mode operand described in chmod, except that: 1. The changes to file mode bits shall be applied to a template instead of to any files. The template shall initially have all file mode bits cleared. 2. The op symbol '-' cannot be the first character of mode; this avoids ambiguity with the optional leading . Since the initial mode is all bits off, there are not any symbolic modes that need to use '-' as the first character. If the is omitted, ... with a new paragraph in RATIONALE: Earlier versions of this standard were silent regarding whether the -perm primary takes into account the file mode creation mask when the op symbols '+' and '-' are used without who being specified, and required the mask to be disregarded when the op symbol '=' is used without who. The latter resulted in a surprising inconsistency with chmod, and also meant that '=' without who just worked the same as '=' with a who of 'a', disallowing useful functionality. Some implementations used the mask anyway, despite the requirement not to. The standard now requires that the way find handles these op symbols is consistent with chmod. Applications that need the old behavior can simply use '=' with a who of 'a' instead of without who. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016)/Issue7+TC2 0001392]: find(1): clarify whether -perm ops - and + should follow chmod
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1392 == Reported By:mohd_akram Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1392 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Mohamed Akram Organization: User Reference: Section:find Page Number:2797 Line Number:91951-91956 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-08-14 12:55 UTC Last Modified: 2020-08-21 17:12 UTC == Summary:find(1): clarify whether -perm ops - and + should follow chmod == -- (0004942) shware_systems (reporter) - 2020-08-21 17:12 https://austingroupbugs.net/view.php?id=1392#c4942 -- Yes, link works this time :-) Issue History Date ModifiedUsername FieldChange == 2020-08-14 12:55 mohd_akram New Issue 2020-08-14 12:55 mohd_akram Name => Mohamed Akram 2020-08-14 12:55 mohd_akram Section => find 2020-08-14 12:55 mohd_akram Page Number => 2797 2020-08-14 12:55 mohd_akram Line Number => 91951-91956 2020-08-15 11:15 joerg Note Added: 0004925 2020-08-16 21:16 mohd_akram Issue Monitored: mohd_akram 2020-08-19 09:22 geoffclare Note Added: 0004926 2020-08-19 10:32 joerg Note Added: 0004929 2020-08-19 11:32 geoffclare Note Added: 0004930 2020-08-19 11:34 geoffclare Note Edited: 0004930 2020-08-21 16:47 mohd_akram Note Added: 0004941 2020-08-21 16:50 mohd_akram Note Edited: 0004941 2020-08-21 16:53 mohd_akram Note Edited: 0004941 2020-08-21 17:12 shware_systems Note Added: 0004942 ==
[1003.1(2016)/Issue7+TC2 0001392]: find(1): clarify whether -perm ops - and + should follow chmod
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1392 == Reported By:mohd_akram Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1392 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Mohamed Akram Organization: User Reference: Section:find Page Number:2797 Line Number:91951-91956 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-08-14 12:55 UTC Last Modified: 2020-08-21 16:47 UTC == Summary:find(1): clarify whether -perm ops - and + should follow chmod == -- (0004941) mohd_akram (reporter) - 2020-08-21 16:47 https://austingroupbugs.net/view.php?id=1392#c4941 -- I think the title I put should be tweaked - the issue is actually + and = (- seems to behave the same due to the 000 starting point). I had posted the = example in the filed GNU bug but forgot about it - hopefully this link will work: https://savannah.gnu.org/bugs/?58654 On macOS: $ chmod =w file $ find file -perm =w file On Fedora: $ chmod =w file $ find file -perm =w It seems that macOS does not ignore the mask even with =, mimicking chmod's behavior. It feels like it would be simpler to defer to chmod in both syntax and semantics because the "symbolic_mode" operand is fairly complicated. This could entail removing the "without regard to the contents of the file mode creation mask of the process" (letting "appropriate" do all the heavy-lifting) and adding at the end that it is "implementation-defined whether + and = ignore the file creation mode mask when `who` is not specified". Issue History Date ModifiedUsername FieldChange == 2020-08-14 12:55 mohd_akram New Issue 2020-08-14 12:55 mohd_akram Name => Mohamed Akram 2020-08-14 12:55 mohd_akram Section => find 2020-08-14 12:55 mohd_akram Page Number => 2797 2020-08-14 12:55 mohd_akram Line Number => 91951-91956 2020-08-15 11:15 joerg Note Added: 0004925 2020-08-16 21:16 mohd_akram Issue Monitored: mohd_akram 2020-08-19 09:22 geoffclare Note Added: 0004926 2020-08-19 10:32 joerg Note Added: 0004929 2020-08-19 11:32 geoffclare Note Added: 0004930 2020-08-19 11:34 geoffclare Note Edited: 0004930 2020-08-21 16:47 mohd_akram Note Added: 0004941 ==
Re: [1003.1(2016)/Issue7+TC2 0001392]: find(1): clarify whether -perm ops - and + should follow chmod
> -- > (0004926) geoffclare (manager) - 2020-08-19 09:22 > https://austingroupbugs.net/view.php?id=1392#c4926 > -- > I think we should issue a "standard is silent" interpretation, thus > allowing both behaviours for Issue 7, but we should make a change in Issue > 8 to require the BSD behaviour. I started looking into a wording change for this, but I'm not too keen on where it would end up. It would have a particular difference from chmod that would "stick out like a sore thumb", which is that when '=' is used without a "who", find ignores the umask but chmod uses it. Is that what BSD find does? Or is it consistent with chmod here (contrary to what the standard requires)? Perhaps we should allow the difference but recommend against it. Something like this: The mode argument is used to represent file mode bits. It shall be processed in an identical matter to the symbolic_mode operand described in chmod, except that: 1. The changes to file mode bits shall be applied to a template instead of to any files. The template shall initially have all file mode bits cleared. 2. The op symbol '-' cannot be the first character of mode; this avoids ambiguity with the optional leading . Since the initial mode is all bits off, there are not any symbolic modes that need to use '-' as the first character. 3. The find utility may, but should not, disregard the contents of the file mode creation mask of the process when the op symbol '=' is used without who being specified. If the is omitted, ... with a note in FUTURE DIRECTIONS: A future version of this standard may require that the -perm primary uses the file mode creation mask in an identical manner to the way chmod uses it in the symbolic_mode operand. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016)/Issue7+TC2 0001392]: find(1): clarify whether -perm ops - and + should follow chmod
A NOTE has been added to this issue. == https://www.austingroupbugs.net/view.php?id=1392 == Reported By:mohd_akram Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1392 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Mohamed Akram Organization: User Reference: Section:find Page Number:2797 Line Number:91951-91956 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-08-14 12:55 UTC Last Modified: 2020-08-19 10:32 UTC == Summary:find(1): clarify whether -perm ops - and + should follow chmod == -- (0004929) joerg (reporter) - 2020-08-19 10:32 https://www.austingroupbugs.net/view.php?id=1392#c4929 -- Given that the find man page points to chmod(1) and that it explicitly mentions '=' to differ somehow from '+', I see this as a hint that -perm must behave similar to chmod(1) which includes the file creation mask. BTW: When I wrote my parser in July 2004 for libfind, I did not check existing find implementations but only the POSIX standard. The background for writing libfindhas been the missing usability of gfind and find from Solaris at that time. So the behavior of libfind is just a consequence of following the standard and what is expected for orthogonal behavior. Regardless of the way you interpret this, we seem to basically agree that the libfind/BSD behavior is the right way to go for the future. P.S. The Solaris implementation behaves the same as gfind for this detail, but I am happy to change this. Issue History Date ModifiedUsername FieldChange == 2020-08-14 12:55 mohd_akram New Issue 2020-08-14 12:55 mohd_akram Name => Mohamed Akram 2020-08-14 12:55 mohd_akram Section => find 2020-08-14 12:55 mohd_akram Page Number => 2797 2020-08-14 12:55 mohd_akram Line Number => 91951-91956 2020-08-15 11:15 joerg Note Added: 0004925 2020-08-16 21:16 mohd_akram Issue Monitored: mohd_akram 2020-08-19 09:22 geoffclare Note Added: 0004926 2020-08-19 10:32 joerg Note Added: 0004929 ==
[1003.1(2016)/Issue7+TC2 0001392]: find(1): clarify whether -perm ops - and + should follow chmod
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1392 == Reported By:mohd_akram Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1392 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Mohamed Akram Organization: User Reference: Section:find Page Number:2797 Line Number:91951-91956 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-08-14 12:55 UTC Last Modified: 2020-08-19 09:22 UTC == Summary:find(1): clarify whether -perm ops - and + should follow chmod == -- (0004926) geoffclare (manager) - 2020-08-19 09:22 https://austingroupbugs.net/view.php?id=1392#c4926 -- > Given that the standard mentions the mask, I believe it is exact enough. I disagree. It only mentions the mask in the statement about '=':'=' shall set the appropriate mode bits, without regard to the contents of the file mode creation mask of the process.It does not mention the mask in the statements about '+' and '-', therefore it is implicitly unspecified whether the mask is used for those. I think we should issue a "standard is silent" interpretation, thus allowing both behaviours for Issue 7, but we should make a change in Issue 8 to require the BSD behaviour. Issue History Date ModifiedUsername FieldChange == 2020-08-14 12:55 mohd_akram New Issue 2020-08-14 12:55 mohd_akram Name => Mohamed Akram 2020-08-14 12:55 mohd_akram Section => find 2020-08-14 12:55 mohd_akram Page Number => 2797 2020-08-14 12:55 mohd_akram Line Number => 91951-91956 2020-08-15 11:15 joerg Note Added: 0004925 2020-08-16 21:16 mohd_akram Issue Monitored: mohd_akram 2020-08-19 09:22 geoffclare Note Added: 0004926 ==
[1003.1(2016)/Issue7+TC2 0001392]: find(1): clarify whether -perm ops - and + should follow chmod
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1392 == Reported By:mohd_akram Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1392 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Mohamed Akram Organization: User Reference: Section:find Page Number:2797 Line Number:91951-91956 Interp Status: --- Final Accepted Text: == Date Submitted: 2020-08-14 12:55 UTC Last Modified: 2020-08-14 12:55 UTC == Summary:find(1): clarify whether -perm ops - and + should follow chmod Description: Currently, BSD/macOS find(1) behave like chmod when it comes to the - and + operators of -perm: $ umask 0022 $ touch file $ chmod +w file $ find file -perm -+w file GNU find behaves differently (https://savannah.gnu.org/bugs/?58654): $ umask 0002 $ touch file $ chmod +w $ find file -perm -+w GNU find treats = and + as equivalent, while BSD find doesn't (which is IMO more useful). Desired Action: Clarify the behavior of find(1) -perm with respect to the - and + operators. == Issue History Date ModifiedUsername FieldChange == 2020-08-14 12:55 mohd_akram New Issue 2020-08-14 12:55 mohd_akram Name => Mohamed Akram 2020-08-14 12:55 mohd_akram Section => find 2020-08-14 12:55 mohd_akram Page Number => 2797 2020-08-14 12:55 mohd_akram Line Number => 91951-91956 ==
