View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001604 | Issue 8 drafts | Shell and Utilities | public | 2022-09-12 16:56 | 2024-06-11 09:12 |
| Reporter | Don Cragun | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Product Version | Draft 2.1 | ||||
| Name | Don Cragun | ||||
| Organization | |||||
| User Reference | |||||
| Section | stty utility | ||||
| Page Number | 3188 | ||||
| Line Number | 108231-108235 | ||||
| Final Accepted Text | 0001604:0006010 | ||||
| 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 | tc3-2008 | ||||
|
|
Two further editorial problems on the stty page have been reported by наб on the mailing list and could be addressed in this bug. I won't repeat the problem descriptions here. The requested changes are: (mail sequence 34874) Change "values" on line 107979 and 107982 to "value". (mail sequence 34875) On ll. 108152, 108155 replace "icanon" with "−icanon". |
|
|
Change italic undef on line 108235 (D2.1) to <tt>"<undef>"</tt> Change "values" on line 107979 and 107982 to "value". On ll. 108152, 108155 replace "icanon" with "−icanon". |
| 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 |
| 2022-10-18 11:32 | geoffclare | Note Added: 0005996 | |
| 2022-10-20 16:20 | geoffclare | Note Added: 0006010 | |
| 2022-10-20 16:20 | geoffclare | Final Accepted Text | => 0001604:0006010 |
| 2022-10-20 16:20 | geoffclare | Status | New => Resolved |
| 2022-10-20 16:20 | geoffclare | Resolution | Open => Accepted As Marked |
| 2022-10-20 16:21 | geoffclare | Tag Attached: tc3-2008 | |
| 2022-11-01 15:08 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:12 | agadmin | Status | Applied => Closed |
