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

[Bob Proulx]

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