Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001604 [Issue 8 drafts] Shell and Utilities Editorial Clarification Requested 2022-09-12 16:56 2022-09-12 16:56
Reporter Don Cragun View Status public  
Assigned To
Priority normal Resolution Open  
Status New   Product Version Draft 2.1
Name Don Cragun
Organization
User Reference
Section stty utility
Page Number 3188
Line Number 108231-108235
Final Accepted Text
Summary 0001604: stty default output for control characters
Description This is copied from austin-group-l e-mail sequence number 34789 posted by наб.

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".

Desired Action The fix would be to simply change italic undef on line 108235 (D2.1)
to monospace <undef> or bold <undef>.
Tags No tags attached.
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2022-09-12 16:56 Don Cragun New Issue
2022-09-12 16:56 Don Cragun Name => Don Cragun
2022-09-12 16:56 Don Cragun Section => stty utility
2022-09-12 16:56 Don Cragun Page Number => 3188
2022-09-12 16:56 Don Cragun Line Number => 108231-108235


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker