On 11/15/2011 10:25 AM, Bjartur Thorlacius wrote: > On Tue, 15 Nov 2011 16:28:35 -0000, Paul Eggert <[email protected]> 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 [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
