Re: possible new feature for chmod

[Paul Eggert]

Steve Summit <address@hidden> 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.