Hi!
Issue 7 and Issue 8 Draft 2.1 say this (XCU, stty, STDOUT, last para.):
If control characters are written as part of the default output, or if
the −a option is specified, control characters shall be written as:
"%s = %s;", <control-character name>, <value>
where <value> is either the character, or some visual representation of
the character if it is non-printable, or the string undef if the
character is disabled.
undef is italicised, and matches the argument to character-valued
attributes like kill. On first glance, this makes sense.
However, every BSD release on the CSRG CDs since 3BSD,
SysIII, and SysVr{1,2,3,4} ‒ that is, every historical system /with/ a
disabling functionality ‒ as well as modern BSD, Illumos,
and the GNU system, render this as "<undef>".
This is very curious! /I/ was very curious, at least.
XPG3 stty (same as XPG2's) does not define the output format
(stty's primary purpose isn't to generate text,
so that fits with the XPG's "don't rely on this format" clause).
The XPG3-XPG4 migration guide lists some changes,
but none of them relevant here.
POSIX.2 Draft 11.2 (the only one extant on the internet :/) says:
If control characters are written as part of the default output,
or if the −a option is
specified, control characters shall be written as:
"%s = %s;", <control-character name>, <value>
where value is either the character, or some visual representation
of the character if it is nonprintable,
or the string <undef> if the character is disabled.
And <undef> is monospace here!
This is "correct": it matches every implementation.
XPG4.2/SUSv1 in its change history cites
Aligned with the ISO/IEC 9945-2: 1993 standard.
for Issue 4 amd says:
If control characters are written as part of the default output,
or if the −a option is specified,
control characters will be written as:
"%s = %s;", <<control>-character name>, <value>
where value is either the character,
or some visual representation of the character if it is non-printable,
or the string <undef> if the character is disabled.
With <undef> in normal font
(this matches the formatting of its own control-character-argument table,
which has ^- and undef in normal font as well).
SUSv2/Issue 5 matches SUSv2 (except for the ^- in the table).
Its FUTURE DIRECTIONS says something about interpretations of P1003.2b,
but in draft 12 of that I didn't see anything relevant to this.
SUSv3/Issue 6 is the first one that formats this in the problematic way
described: both undef in the control-character-argument table and in the
STDOUT section are no-<> and italic:
If control characters are written as part of the default output,
or if the -a option is specified,
control characters shall be written as:
"%s = %s;", <control-character name>, <value>
where <value> is either the character, or some visual representation
of the character if it is non-printable, or the string undef if the
character is disabled.
The only diff items for Issue 6 seem to be removing legacy items and
fixing the description of nl and -nl in XCU/TC1/D6/37.
I only checked the HTML version, but the formatting and wording are the
same for Issue 7 (HTML) and Issue 8 Draft 2.1 (PDF).
My naive interpretation of this is that, after loss of monospacing from
POSIX.2 to SUSv1, at some point in Issue 6's creation, "<undef>" was
taken to mean literal undef, i.e. italic undef, which is wrong,
but makes sense since use of <>s is very common to mean
"enclosed literal" or "literal symbol".
The fix would be to simply change italic undef on line 108235 (D2.1)
to monospace <undef> or bold <undef>.
Best,
наб
Note: idk how well this mail will render on the Open Group webmail
interface due to its heavy use of <>;
I've been pestering the contact box to fix "injecting the literal
mail text as HTML" but this appears to be impossible.
signature.asc
Description: PGP signature
