[TUHS] svr2 delete behavior

John Cowan cowan at ccil.org
Tue Dec 28 09:52:17 AEST 2021


On Mon, Dec 27, 2021 at 9:56 AM Will Senn <will.senn at gmail.com> wrote:


> I hadn't tried it in v6 in a while. I'd pretty much resigned myself to #
> and @. But I see the effect in v6, even without changing stty and it
> 'works', but in svr2, if I type lsa and then hit ^H it backs up a place,
> but then when I press enter the shell says something along the lines of -
> lsa^H: not found.
>

That's exactly what you expect when ^H is not magic: it is echoed back to
/dev/tty like any other normal character, and your emulator does what ^H
means per X3.4: it backs up the cursor by 1 column.

But by adding stty erase ^H, it then 'works' the same as in v6. Seth's
> steer regarding setting erase and echoe 'fixed' things, once I figured out
> that having DEL doubling as intr wasn't ideal.
>

A nice hack in stty (though I am not sure how far back it goes): you can
enter ^H either with an actual backspace character or with the
two-character sequence ^ followed by h or H.  The second form has the
advantage that it can be typed correctly no matter how badly you have
screwed up your control characters.

Oh, the mysteries of terminal interaction.
>

Not _that_ mysterious.  Grab ECMA standard 48 (technically equivalent
to ANSI X3.64) at <
https://www.ecma-international.org/wp-content/uploads/ECMA-48_5th_edition_june_1991.pdf>
and
you'll know all about how terminal emulators behave.  It isn't hard to
read, once you have learned to read "00/13" as hex 0D, which everyone knows
right off is CR.  (If not, <asciitable.com> is your friend.)  The reason
for this bizarre row/column notation is so that escape sequences are always
binary no matter the encoding: the sequence that introduces multi-character
control sequences is usually spoken of as "ESC [", but technically it has
to be sent to a conforming terminal as "\x1B\x45" even if the encoding is
EBCDIC, where "ESC [" would be "\x27\xBA" (at least in the US/Canada flavor
of EBCDIC).

Bugs are another matter, of course.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20211227/d09cd237/attachment.htm>


More information about the TUHS mailing list