Re: [PATCH] doc: update for ISO/IEC 80000-13

[Jim Meyering]

Eric Blake wrote:

> On 11/15/2011 10:25 AM, Bjartur Thorlacius wrote:
>> On Tue, 15 Nov 2011 16:28:35 -0000, Paul Eggert <address@hidden> wrote:
>>>
>>> +      /* On GNU/Hurd hosts, getuid etc. can fail and return -1.
>>> +         However, on GNU/Linux hosts, uid_t is an unsigned value and
>>> +         getuid etc. can return the positive value (uid_t) -1.  To
>>> +         handle both cases correctly, consider getuid etc. to fail if
>>> +         it returns a negative value (a value that is impossible on
>>> +         GNU/Linux hosts).
>>> +
>>> +         GNU/Linux sysadmins should not give users the UID (uid_t) -1
>>> +         even though uid_t is unsigned, as system calls like chown would
>>> +         not have the desired behavior with such a UID, and other
>>> +         coreutils applications therefore do not support such a UID.
>>> +         However, 'id' makes a special attempt to handle this UID, to
>>> +         help people diagnose the problem.  */
>> s/etc\./e.t.c./g?
>
> No.  "etc." is the correct abbreviation for "et cetera"; the spelling
> "e.t.c." is not a valid abbreviation.
>
> However, in texinfo, it is sometimes necessary to write "etc.@:" so that
> formatting into info does not treat the next word as the start of a new
> sentence; this may be one of those cases.  (info texinfo 'not ending a
> sentence').
>
> Also, I tend to see "etc." used primarily in the context of a list, when
> at least two items have already been given (so that it is more obvious
> what similar items have been omitted from the list).  It's hard to see
> what similar functions are implied when only the one item getuid is
> present before "etc.".  Perhaps it may be easier to read as:
>
> On GNU/Hurd hosts, identification functions (getuid, getgid, etc.) can
> fail and return -1.

I prefer that, too.  Thanks.
Would you care to adjust it?