On 21/11/13 17:09, Eric Blake wrote:
> But as written, the usage text implies that we can omit both OWNER and
> :GROUP and still have a valid call, as in:
>
> chown /tmp/bla
>
> which isn't quite true. Alas, the only way I can see to rewrite the
> fact that SOME spec is necessary, while still highlighting the GNU
> extension of omitting OWNER, is to split the usage into two lines:
>
> Usage: chown [OPTION]... OWNER[:[GROUP]] FILE...
> or: chown [OPTION]... :GROUP FILE...
>
> Thoughts? Should we reopen this bug to track the doc bug[s]?
>
> Alas, ...
Hehe.
I agree, two lines should be the only way to express that
there are 4 possibilities:
chown OWNER
chown OWNER:
chown OWNER:GROUP
chwon :GROUP
But shouldn't all 4 possibilities allow both OWNER and GROUP to be
specified either as NAME or as numerical ID ?
chown OWNERNAME == chown OWNERID [*]
chown OWNERNAME: == chown OWNERID: [**]
chown OWNERNAME:GROUPNAME == chown OWNERID:GROUPID[*]
chwon :GROUPNAME ==chown :GROUPID [*]
[*] working as expected
[**] NOT working as expected (see my bug report) ... but why ?
Especially as:
chown 1001:mine /tmp/bla
and
chown me:1001 /tmp/bla
works fine!
(with mine == 1001)
Tormen
