Re: Nostalgia meets modern hardware
Just be a little careful. Although the VT100 is regarded as a single terminal, it was actually a family of terminals.
The VT100 was the original, built with several boards (ever wondered why the screen unit was asymmetrical, there was a card cage on the RHS) , and had options (such as the Advanced Video Option AVO) and some options regarding the amount of memory, which determined whether the 132 column mode could use all 24 lines.
What most people refer to as a VT100 was actually a VT102, which was a re-implementation on a single board with new firmware, but no upgrades. This is what most vt100 termcap/terminfo entries implement.
As a consequence, there are minor differences between the behaviour, and if you look at either /etc/termcap, or the various terminfo files, there are different entries for different models and setups.
I thought I was well versed in termcap/terminfo and the vt100 entries, but the differences tripped me (and bash) up when I was building the Peter Hizalev version of Geoff's VT100 kit, I found out that the original vt100 and the Hizalev version of the code is accurate to an original vt100, and this has one unexpected feature, in that a NULL (ASCII x00) is translated to a space by the VT100 (documented in the vt100 operators manual or programming card. But the GNU implementation of terminfo and it's vt100 entry used NULL as the timing padding character, which the terminfo entry will use at higher serial speeds.
Later models of the vt family do not print a space when a NULL is received, so don't suffer the same problem, and this is not seen when an xterm or xterm derived emulator, as again, NULLs do nothing, and is not a huge problem most of the time (although spurious spaces in the output from some commands can bee seen), but bash does cause a problem.
In a traditional old-school UNIX system with the Bourne shell or Ksh, the handling of rubout is left to the TTY line discipline, but bash does something different. It puts the terminal into a mode that turns off the line discipline (mainly so you can use the arrow keys for command line editing), and handles rubout itself. Instead of doing a "backspace-space-backspace" sequence, actually does something like "cub1" followed by a "el", which deletes to the end of line, but at high speeds will actually cause padding characters to be generated, which on an original VT100 or close-to-perfect emulation, actually causes space characters in the line you're typing when deleting characters.
This does not happen if you are using a shell other than bash (I have checked with the official ksh and some other shells), and also does not happen if you either modify the terminfo entry to include the capability "npc", either in the global terminfo for vt100, or in a local terminfo like .terminfo or pointed to by the TERMINFO environment variable.
I really ought to document this as a bug in the ncurses-term package, or possibly bash. It probably won't affect anybody outside of the retro community, as how many people put VT100 terminals on serial lines to modern Linux systems?
