[ On Sunday, January 18, 2004 at 18:48:13 (+0100), Jesper Louis Andersen wrote: ]
> Subject: Re: chmod(1) and '+X'
>
> Quoting Perry E. Metzger (perry@piermont.com):
> 
> > > IRIX' chmod and GNU chmod remove the 'x' bit.
> > 
> > If Solaris' does the same, I'd say we have consensus.
> 
> Hmm, is all those anything but old SystemV descendants?

"old" is a relative term here  :-)

If I'm not mistaken each of the SysVr4 derivatives still in relatively
wide distribution has always had a quite independent source tree (and
that no doubt goes double or triple for Sun) and traditionally both Sun
and SGI have been quite enamoured with their own local changes, so
there's still lots of room for disagreement between them.  :-)

I'd guess Sun would be more likely to make a change to the way a tool
like "chmod" would work than SGI would, though I suppose that's not
really relevant.  Sun also have had a tradition of providing separate
standards-compliant tools (xpg4), and SGI may have done the same (I have
much less experience with SGI releases).

>  What about
> 4.4bsd and it's behaviour? 

We can use the source for that comparison.  :-)

From what I can see just from a very quick scan of the diffs of 4.4BSD
setmode.c vs NetBSD's setmode.c, NetBSD's chmod will have diverged in
how it interprets its parameters a bit from 4.4BSD's, though according
to the changelog it's mostly a result of bug fixes by cdg that are not
directly related to the 'X' permissions modifier.


> (no, I am not on sure ground here, I just want to weed out the 
> possibility that there are 2 main ways of doing it)

I NetBSD's manual page (which remains unchanged in this part since
4.4BSD) has as good an explanation of 'X' as any.  Alone this seems to
indicate the documented issue with '-X' is indeed in conflict with the
manual page:

           X       The execute/search bits if the file is a directory or any
                   of the execute/search bits are set in the original (unmodi-
                   fied) mode.  Operations with the perm symbol ``X'' are only
                   meaningful in conjunction with the op symbol ``+'', and are
                   ignored in all other cases.

As for standards-compatability, well as I think has already been quoted,
IEEE Std 1003.1-2001 has this to say:

     The perm symbol X shall represent the execute/search portion of the
     file mode bits if the file is a directory or if the current
     (unmodified) file mode bits have at least one of the execute bits
     (S_IXUSR, S_IXGRP, or S_IXOTH) set.  It shall be ignored if the
     file is not a directory and none of the execute bits are set in the
     current file mode bits.

First off these two sentences seem to contradict themselves w.r.t. what
should happen when the file is not a directory, however I would put more
weight in the second sentence.

The RATIONALE section of IEEE Std 1003.1-2001 explains why the current
behaviour of NetBSD's "chmod" w.r.t. "-X" (and hopefully "=X") is
correct and that our manual page is simply out-of-date:

     The X perm symbol was adopted from BSD-based systems because it
     provides commonly desired functionality when doing recursive (-R
     option) modifications.  Similar functionality is not provided by
     the find utility.  Historical BSD versions of chmod, however, only
     supported X with op+; it has been extended in this volume of IEEE
     Std 1003.1-2001 because it is also useful with op=.  (It has also
     been added for op- even though it duplicates x, in this case,
     because it is intuitive and easier to explain.)

As for acting on non-directories, well if it does then that may be a
separate bug (or deviation from POSIX) in the NetBSD implementation

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>