Re: Bug#249177: coreutils: chown is not POSIXLY_CORRECT even when the variable is set

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Here are some more thoughts on coreutils chown etc.  I guess I'm
> volunteering to implement these if there's interest...

Great!
The differing meanings of --dereference has bothered me, too.

> * Coreutils currently assigns two distinct meanings to the
>   "--dereference" option.  In some cases (e.g., chown) it means
>   "dereference symlinks when you apply the primitive operation" (i.e.,
>   use chown() rather than lchown()).  In other cases (e.g., "du") it
>   means "dereference symlinks when you walk through the tree" (i.e.,
>   use ftw with FTS_LOGICAL rather than FTS_PHYSICAL).
>
>   This is confusing and needs to be cleaned up.  To be
>   backward-compatible, we can't change the meaning of "--dereference".
>   But we can add new, cleaner options, as follows:
>
>   For the BSD -H/-L/-P options, which control file tree walking:
>
>     -P = --walk=physical
>     -H = --walk=hybrid  (I have no idea what -H originally stood for.)
>     -L = --walk=logical
>
>   For the -h option of chown, and its inverse, which control whether
>   the chown command uses lchown() or chown():
>
>     -h = --no-follow
>          --follow
>
>   The follow and walk options are independent.  Their default settings
>   probably depend on the command and other options, e.g., chown -RP
>   implies a default of -h.  --dereference and --no-dereference can be
>   kept as undocumented aliases for the above options.

Those sound fine.

> * With or without the above change, there's a problem with trying to
>   change everything in sight.  Either you use chown -RL (chown
>   --recursive --logical-walk) and miss the symbolic links that you
>   find, or you use chown -RLh (chown --recursive --logical-walk
>   --no-follow) and you miss the targets of the symlinks.  Perhaps this
>   isn't worth worrying about, but I thought I'd mention it.

I'm inclined to agree that this isn't worth worrying about.

> * Minor suggestion: "chown : file" should invoke chown with uid and
>   gid both set to -1, so that the file ownership and group doesn't
>   change but the setuid/setgid bits are cleared (and perhaps ACLs are
>   removed).  This might be useful.

POSIX seems to require owner[:group].
Is it compliant to accept `:'?

> * chmod and touch should add support for -h so that they can use
>   lchmod and lutimes, respectively, on hosts that have these system
>   calls (e.g., FreeBSD 3.0 and later).

Good idea.