On 2010-12-06, at 09:19, Aristotle Pagaltzis wrote:
* Peter da Silva <pe...@taronga.com> [2010-11-29 00:05]:
On 2010-11-28, at 15:35, Aristotle Pagaltzis wrote:
It is not a bug. It is the place we have arrived after years
of walking down the path that followed the wrong direction
chosen from the start. I am not complaining about the hack
itself.
What wrong direction was chosen in 1969?
Leaving terminal support entirely up to userspace, via libraries?
That didn't happen. UNIX had as much terminal support as was possible to
implement in the kernel. There was no room for something as complex as termcap,
let alone curses, in the address space available to the kernel in 1969 or even
1979. I implemented a termcap for CP/M and MS-DOS in the early '80s. It took
about 8K of code and associated data. The kernel only had 64k code available,
and had already pushed the 1k environment/argv array into user space to save
room.
So now there are several of those, with different conventions for
how to configure each, and each needs to be configured for each
terminal, leaving room for things to not line up correctly.
There's two families of these libraries, termcap and terminfo. Current terminfo libraries
supports both APIs. I don't know where you're getting "several" from.
Some
things involve environment variables
If a program needs more than TERM= it's doing it wrong.
TERMCAP= is an optimization. You can leave it out.
which makes it awkward to
get the right settings into the right place consistently, esp.
without restarting long-running programs like X. You get fun
times if you do things such as start a program under an
rxvt-unicode terminal and reattach it under a putty-256color one.
If this is a problem, set your term to a minimal ANSI X3.64.
The only worse clusterfuck that comes to mind from own experience
was printing under DOS.
How about terminal support on DOS and CP/M. There's a reason I implemented
TERMCAP for it. It was a huge improvement.
