Eric Blake wrote: > 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.
I prefer that, too. Thanks. Would you care to adjust it?
