From: John Cowan <firstname.lastname@example.org>
To: Will Senn <email@example.com>
Cc: TUHS main list <firstname.lastname@example.org>,
Noel Chiappa <email@example.com>
Subject: Re: [TUHS] svr2 delete behavior
Date: Mon, 27 Dec 2021 18:52:17 -0500 [thread overview]
Message-ID: <CAD2gp_R06mwHsFuoRrcw3fFLttLzpyJSq-F+Lz7YzFPz5z=Y0w@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]
On Mon, Dec 27, 2021 at 9:56 AM Will Senn <firstname.lastname@example.org> 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 <
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
Bugs are another matter, of course.
[-- Attachment #2: Type: text/html, Size: 4059 bytes --]
next prev parent reply other threads:[~2021-12-27 23:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-27 14:37 Noel Chiappa
2021-12-27 14:56 ` Will Senn
2021-12-27 23:52 ` John Cowan [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-12-27 0:31 Will Senn
2021-12-27 1:24 ` Seth Morabito
2021-12-27 14:39 ` Will Senn
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).