At 2019-09-16T13:47:27-0700, Jon Steinhart wrote: > G. Branden Robinson writes: > > _info_nol "> \033[46m\033[30mSTATUS:\033[0m " > > > > Why write something portable when you can be "close to the metal"? :-/ > > > > I gently steer people to better ways when the occasion presents itself. [...] > > We can have an interesting discussion of the definition of "better ways". Here I think we have a layering violation. Why on earth would a CPU microarchitectural flaw detector need to know or care about the details terminal control sequences? _Anything_ that provides an abstraction of the terminal is an improvement on the above. > I see termcap as a great solution for the days in which there was > little standardization. Setting aside the specificity of "termcap", sure. Something was needed to gather up the absurd efflorescence of implementation details among hardware terminals and present programmers (and users struggling to interact with the system) something simpler and more intention-oriented. You want "bold, if the device can do it", not a giant switch statement encompassing '\033[1m', '\033ya', '\033yA', '\033<', '\2331m', '\033[1m' with a parameter after it, '\033[7m', \033[=15F', ... And if the device _can't_ do bold, you want to be able to decide for yourself whether you don't care if the boldness is left out, or be able to query that interface layer about it and program your own fallback (use indentation, full capitalization, an "IMPORTANT:" prefix, etc.) in the event the capability is absent. > But it's probably pretty hard to find a non-conforming terminal > nowadays so I think that it's better to avoid obfuscation. I've attached an example of the sort of thing I do. It has a lot of comments, so is inappropriate for inlining on a list full of Unix grognards. ;-) > Were it me I would have a comment that referenced the page and section > number in the standard. This is a good idea, but its benefit can be limited for ISO standards, which are often paywalled. In this case the controlling standard is ISO 6429. Fortunately it's largely parallel to ECMA-48 which is freely available. In this case you want ECMA-48, pp. 61-63[1]. > Since we like debating the merits of old technology, somebody can kick > off a termcap versus terminfo discussion :-) terminfo is better than termcap in the same way that Fortran 77 is better than Microsoft BASIC for 8-bit microcomputers--identifier length. Fortran 77, 6 characters. MS BASIC, 2. termcap, 2. terminfo, 5. Of course, that argument could be turned around rather precisely for those who prize "terseness". I reckon one of the reasons that function names in the Unix kernel were allowed to grow as long as they did--while still being limited to 6 characters for linkage reasons--was because the precious space of 1- and 2-letter external identifiers was held sacrosanct for user programs. There but for that grace would 'swtch()' have gone as 'sw()', and 'creat()' as 'cr()', perhaps. No such considerations availed in the namespace for executable programs. ;-) Regards, Branden [1] https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf