[TUHS] better ways and termcap vs. terminfo for commentary)

[G. Branden Robinson]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.sh
Type: application/x-sh
Size: 1962 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/82eb0f39/attachment.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/82eb0f39/attachment.sig>