Steve Summit <[EMAIL PROTECTED]> writes: > I don't have a copy of Posix.1 handy,
Please see the section "Grammar for chmod" in: <http://www.opengroup.org/onlinepubs/007904975/utilities/chmod.html> The exact POSIX syntax for chmod is that a symbolic mode is a series of one or more clauses separated by commas, where each clause matches the following extended regular expression: [ugoa]*([-+=]([ugo]|[rwxXst]*))+ I read the POSIX spec more carefully, and discovered some good news and some bad news. The good news is that there is an escape hatch that will let us do what you want with 'chmod -r...' and still conform to POSIX. This escape hatch works for 'chmod' only, not for the other mode-string commands like 'mkdir'. The basic idea is that POSIX doesn't allow portable programs to say this: chmod -r file This is because the chmod command might have an implementation-defined option named '-r' that does something completely different. Portable programs are supposed to say this instead: chmod -- -r file Hence POSIX allows us to define 'chmod -r' to mean whatever we like (so long as the -r is not preceded by '--'), and we don't need to worry about POSIXLY_CORRECT if we change its meaning. This trick works for 'chmod' only; not for the other mode-using commands like 'mkdir'. But this leads me to wonder: how does your proposal work for leading "--"? For example, what does it do with this? chmod --wxrwxrwx file This uses valid 'ls -l' output, but won't it confuse getopt_long? For example, does this mean we have to put all long options of the form "--[w][-Ssx][-r][-w][-Ssx][-r][-w][-Ttx].?" into the table that we pass to getopt_long? This sounds messy. Now, here's the bad news: 'ls -l' can output 'u', 'g', 'o', '=', and '+' in its mode strings. Here is the general format of POSIX 'ls -l' mode strings: .[-r][-w][-Ssx][-r][-w][-Ssx][-r][-w][-Ttx]. The '.'s here stand for any printable character, including space. For details, please see <http://www.opengroup.org/onlinepubs/007904975/utilities/ls.html>. GNU 'ls' uses a special case of that more-general syntax: [-bcdplsmnDCM?][-r][-w][-Ssx][-r][-w][-Ssx][-r][-w][-Ttx][ +] but if we're going to make this change to chmod, we should allow any character that POSIX 'ls' can generate, so that chmod can accept the output of non-GNU 'ls'. > I assume Posix doesn't say so, but I think we can agree that a > single "term" that contains two separate '-'s (or two '+'s or two > '='s, for that matter) is borderline, and a term that contains two > '-'s followed by the same characters, or a '-' not followed by any > character at all, is bogus, and that any of these is deserving of at > least a warning. I don't have that impression. I think the syntax was designed to allow clauses like this: u-rg-rwo-rwx and I don't think that such a clause should get a warning. This clause is uncomfortably close to valid 'ls -l' output. I agree that some of the valid POSIX chmod use cases are indeed outlandish, but I don't think it's trivial to visually distinguish between the chmod syntax and the ls -l syntax, for cases that are not that unusual. We need the distinguishing rule to be trivial for our users' benefit, so that they immediately know which strings are the new (ls -l style) clauses and which are the old (POSIX-style) clauses. Otherwise there will be confusion in the documentation, in the usage messages, and (most importantly) in the users's minds. Also, we need to think about future extensions by POSIX to either the ls -l or the chmod syntax. They could cause collisions in the future, even if we barely avoid the collisions now. > The leading %, clever as it is in absolutely ruling out the > faintest possible of ambiguity, bothers me, because it seems > arbitrary and unnecessary (and therefore ugly). How about '@' instead? It's a bit prettier. > If the founding fathers had had this idea back in Unix's youth, they > wouldn't have felt the need for explicit disambiguation Yes, but most likely they would have rearranged the ls and chmod syntaxes slightly to prevent any possible ambiguity. For example, they could have made 'ls' print '_' instead of '-'. Unfortunately we can't change 'ls' output format now; too many programs depend on it. > My concern was the opposite, that someone would type such a string, > intending it to be interpreted as an ls-style mode string, and get > unexpected results when it was processed as a Posix-style mode > string, instead. Good point, but I don't see an easy way to satisfy it, given the above glitches. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
