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

[Eric Blake]

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.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature