merge 28912 28914 tag 28912 notabug thanks On 10/20/2017 04:35 AM, Ricky Tigg wrote: >>From the followings inputs it should be expected to produce regarding the > input format either error or a warning messages. As empty sets all the > input tests have been conducted. Thanks for the report. However, I think you misunderstand the documentation; all of the examples posted in your email are valid parses (even if they do nothing), and intentionally do not trigger an error or a warning message, nor should they. It would probably do you a service to re-read the manual on how coreutils parses symbolic mode strings: https://www.gnu.org/software/coreutils/manual/coreutils.html#Setting-Permissions Every chmod mode string is divided into three parts: USERS (the leading [ugoa]...), OPERATIONS (the [-+=]), and the PERMISSIONS (either zero or more from [rwxXst] or a single letter from [ugo]), and it is permissible to have more than one OPERATION in a single string (the manual gives og+rX-w as an example with two operations both performed on the USERS of og). The manual also states that omitting PERMISSIONS makes little sense for the - or + OPERATION, but is not forbidden (it makes more sense for the = OPERATION). > > Examples of such validated combinations of format: > > # chmod o- </file> This is a valid command line. It says to subtract permissions from the 'other' bits, but then because it omits what permissions to subtract, nothing is subtracted, so it is a successful no-op. > > # chmod + </file> This is a valid command line. Because the USERS part is empty, it says to use umask for determining which set of mode bits to operate on (the manual says that is typically not useful except with the + OPERATION); the + then says to add permissions, and then the empty set of permissions to add mean it is a successful no-op. > > # chmod agogagagouugogogaauagooaguaguououau=========+++----==--++++--- > </file> This is a valid command line. You've done a very round-about way of spelling 'a' (repeating letters in USERS is permitted); then you are specifying multiple operations on that set of users (performing an '=' change with no permissions, performing another '=' change with no permissions, etc., and finally performing a '-' change with no permissions'). About the only thing that is not parseable is the completely empty string: $ chmod '' foo chmod: invalid mode: ‘’ Try 'chmod --help' for more information. as the parser requires an OPERATION. In fact, in new enough versions, the 'chmod --help' output uses a regex: "Each MODE is of the form '[ugoa]*([-+=]([rwxXst]*|[ugo]))+|[-+=][0-7]+'." which is a rather accurate representation that matches all of the examples you gave. As such, I'm closing this as not a bug. However, feel free to add further comments to this thread if you have further evidence for coreutils not doing something required/permitted by POSIX, or not doing something that matches what is already documented behavior. > > On Linux in terminal, by invoking "man chmod 2" it is noticeable from the > output that links related to internet sites are mentioned without HTTPS > format while they are currently available: > > “GNU coreutils online help: <http://www.gnu.org/software/coreutils/> 'man chmod 2' is not a typical command line; did you mean 'man 2 chmod' (to pull up the page for the syscall) vs. 'man 1 chmod' (to pull up the utility)? But yes, although this is an unrelated bug report, I can agree that we are slowly making the move to make more and more GNU software documentation refer to https rather than http. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
--- End Message ---