Bjartur Thorlacius wrote: > Paul Eggert 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?
Unfortunately that wouldn't produce a proper usage. Since "etc." is an abbreviation for the latin "et cetera". The latin meaning being "and other things" or "and so forth". But I agree that doesn't quite fit here. (For example neither "getuid and so forth" nor "getuid and other things" sound appropriate.) I think "et al." the latin abbreviation meaning "and others" was actually desired here. (For example "getuid and others".) > Personally, I had to read the second instance of "etc." three times > before being sure I had inferred the correct semantics of the dot > (while I had no problem with the first instance). This probably > stems from stricter punctuation rules in my native language when > compared with English, but I figure this simple change might help > another or two speakers of English as a second language while > harming no one. > [/nitpick] The best way to avoid confusion when using latin abbreviations is to not use them at all. s/etc\./and others/ Bob
