From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27145 invoked from network); 27 Dec 2021 23:53:11 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 27 Dec 2021 23:53:11 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 3C8EB9CFC3; Tue, 28 Dec 2021 09:53:09 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 6C0EF9CEA7; Tue, 28 Dec 2021 09:52:37 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ccil-org.20210112.gappssmtp.com header.i=@ccil-org.20210112.gappssmtp.com header.b="gOVfwJUl"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9F39A9CEA7; Tue, 28 Dec 2021 09:52:34 +1000 (AEST) Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by minnie.tuhs.org (Postfix) with ESMTPS id 244899CE84 for ; Tue, 28 Dec 2021 09:52:33 +1000 (AEST) Received: by mail-wm1-f48.google.com with SMTP id e5so10155530wmq.1 for ; Mon, 27 Dec 2021 15:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mSz1yDN/NTbp/OuTKt51xnrZ1V9hgM+lbDZ3TrCANn4=; b=gOVfwJUl3oYKzvjrHFlGLNGDryyx+4ISDnIuEh3ZJ7oK9xiLZA3fzot4E47VL9iZac cdsKd1sYZtxmQ2WAlIOyMWaXD8jcl7l+MXJ59xxxZncwmw77lXp76Q7/jVscrxfJTouu B5Qj57mZ9E2GOiaQDe4wqXYDwnU4MNlFb7Nu2c/kni7aEPyUlyQ9XzFXypiIGDmp0NvS nh7As/XNv+oww2Y87dD+2JfTQrk52EetIUkNzk1AP05E5sqwfNXYrcCEpK/5PInfsOeb QTgRbZHYj+YXjowSHJaCe9RbwAFKhBYWUsa6NsNta0EFPhGA1Jc5xhN/bgdGQMPx0m4P tj0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mSz1yDN/NTbp/OuTKt51xnrZ1V9hgM+lbDZ3TrCANn4=; b=VMAyVaBCGkdRJTuufwahtbZJDUcztC5HIvTzOELoJVkLWMzW54hZy9svr+jppGwxLp X0keGMtLW1+EEWQX+f5sOTRjvQxmFk2X1mdRpXbzkS8ElX1vP1SawrlR7oME/P7W0dKV NeP/K8WLSJdpiecnHzEq2ErS5oN47GhggpzKSsVFvKtJE3f1DtSFoR5vdXWAqS6ZiocL E6pRwhRfuDNP/jWg3oEPkvhcoUPXlaRX29AqENTaa7TIj8tDakL+/aZH3pqCTaALHriv iJZyojAz+547GOEeaYiUop6/+7UGDlNHVRcmwTcCopN7H8zIrbXaRxU7L78/Q1fn4/CJ 2OWQ== X-Gm-Message-State: AOAM532HakJxuqBEwMLDKbok7TQ/fq5MHNWEPb5GvGgfKH8N2zg3oydW Ng5tvtySPt0jCUCRxPb7Q+UNxxlesrx6Bei/CwUeYiaZhehcHw== X-Google-Smtp-Source: ABdhPJwhNLVekp3qmSWQ60rY6Gs5JPQ9l8AkfoNXHZFBsF9gh0T4bBi6PCd/tfhiPPRUbQketzzshf/JGBf0OfxrODI= X-Received: by 2002:a7b:ce01:: with SMTP id m1mr15036619wmc.187.1640649151431; Mon, 27 Dec 2021 15:52:31 -0800 (PST) MIME-Version: 1.0 References: <20211227143743.B798F18C073@mercury.lcs.mit.edu> In-Reply-To: From: John Cowan Date: Mon, 27 Dec 2021 18:52:17 -0500 Message-ID: To: Will Senn Content-Type: multipart/alternative; boundary="000000000000df5a1605d4296525" Subject: Re: [TUHS] svr2 delete behavior X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list , Noel Chiappa Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000df5a1605d4296525 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 27, 2021 at 9:56 AM Will Senn 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, 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. > --000000000000df5a1605d4296525 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 27, 2= 021 at 9:56 AM Will Senn <will.se= nn@gmail.com> wrote:
=C2=A0
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 ot= her normal character, and your emulator does what ^H means per X3.4: it bac= ks 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 eith= er with an actual backspace character or with the two-character sequence ^ = followed by h or H.=C2=A0 The second form has the advantage that it can be = typed correctly no matter how badly you have screwed up your control charac= ters.

Oh, = the mysteries of terminal interaction.

Not _that_ mysterious.=C2=A0 Grab ECMA standa= rd 48 (technically equivalent to=C2=A0ANSI X3.64)=C2=A0at <https://www.ecma-international.org/wp-content/uploads/ECMA-48_5= th_edition_june_1991.pdf>=C2=A0and you'll know=C2=A0all=C2=A0abo= ut how terminal emulators behave.=C2=A0 It isn't hard to read, once you= have learned to read "00/13"=C2=A0as hex 0D, which everyone know= s right off is CR.=C2=A0 (If not, <asc= iitable.com> is your friend.)=C2=A0 The reason for this bizarre row/= column notation is so that escape sequences=C2=A0are=C2=A0always binary no = matter the encoding: the sequence that introduces multi-character control s= equences=C2=A0is usually spoken of=C2=A0as "ESC [", but technical= ly it has to be sent to=C2=A0a conforming=C2=A0terminal as "\x1B\x45&q= uot; even if the encoding is EBCDIC, where "ESC [" would be "= ;\x27\xBA" (at least in the US/Canada flavor of EBCDIC).

Bugs=C2=A0are=C2=A0an= other matter, of course.
--000000000000df5a1605d4296525--