Hi наб,
Thank you for your work on this issue. It has been filed as Austin Group
Defect Tracker issue #1604. See https://austingroupbugs.net/view.php?id=1604
Cheers,
Don
> On Sep 10, 2022, at 5:09 AM, наб via austin-group-l at The Open Group
> <austin-group-l@opengroup.org> wrote:
>
> 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.
