* [TUHS] svr2 delete behavior
@ 2021-12-27 0:31 Will Senn
2021-12-27 1:24 ` Seth Morabito
0 siblings, 1 reply; 6+ messages in thread
From: Will Senn @ 2021-12-27 0:31 UTC (permalink / raw)
To: TUHS main list
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]
Did svr2 have anything similar to modern behavior when handling the
delete/backspace key where the character is deleted from the input and
rubbed out? The default, like in v6/v7 for erase and kill is # and @. I
can live with this, if I can't get it to do the rubout, because at least
you can see the # in the input, but if I can figure out how to get it to
rubout the last character, I'd map erase to DEL, which I believe to be
^U (but since it's invisible, it's confusing when it doesn't rubout).
Will
[-- Attachment #2: Type: text/html, Size: 761 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] svr2 delete behavior
2021-12-27 0:31 [TUHS] svr2 delete behavior Will Senn
@ 2021-12-27 1:24 ` Seth Morabito
2021-12-27 14:39 ` Will Senn
0 siblings, 1 reply; 6+ messages in thread
From: Seth Morabito @ 2021-12-27 1:24 UTC (permalink / raw)
To: tuhs
[-- Attachment #1: Type: text/plain, Size: 781 bytes --]
On Sun, Dec 26, 2021, at 4:31 PM, Will Senn wrote:
> Did svr2 have anything similar to modern behavior when handling the delete/backspace key where the character is deleted from the input and rubbed out? The default, like in v6/v7 for erase and kill is # and @. I can live with this, if I can't get it to do the rubout, because at least you can see the # in the input, but if I can figure out how to get it to rubout the last character, I'd map erase to DEL, which I believe to be ^U (but since it's invisible, it's confusing when it doesn't rubout).
>
> Will
You should be able to do `stty erase \^H` and `stty echoe` to get the rubout behavior you want with ^H (and of course you can combine them into one stty line)
-Seth
--
Seth Morabito
Poulsbo, WA
web@loomcom.com
[-- Attachment #2: Type: text/html, Size: 1557 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] svr2 delete behavior
2021-12-27 1:24 ` Seth Morabito
@ 2021-12-27 14:39 ` Will Senn
0 siblings, 0 replies; 6+ messages in thread
From: Will Senn @ 2021-12-27 14:39 UTC (permalink / raw)
To: Seth Morabito, tuhs
[-- Attachment #1: Type: text/plain, Size: 988 bytes --]
On 12/26/21 7:24 PM, Seth Morabito wrote:
> On Sun, Dec 26, 2021, at 4:31 PM, Will Senn wrote:
>> Did svr2 have anything similar to modern behavior when handling the
>> delete/backspace key where the character is deleted from the input
>> and rubbed out? The default, like in v6/v7 for erase and kill is #
>> and @. I can live with this, if I can't get it to do the rubout,
>> because at least you can see the # in the input, but if I can figure
>> out how to get it to rubout the last character, I'd map erase to DEL,
>> which I believe to be ^U (but since it's invisible, it's confusing
>> when it doesn't rubout).
>>
>> Will
>
> You should be able to do `stty erase \^H` and `stty echoe` to get the
> rubout behavior you want with ^H (and of course you can combine them
> into one stty line)
>
> -Seth
> --
> Seth Morabito
> Poulsbo, WA
> web@loomcom.com
>
>
Got it working:
echo 'stty intr \^c erase \^? kill \^u echoe' >> .profile
relogin, and it works.
Thanks!
[-- Attachment #2: Type: text/html, Size: 2712 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] svr2 delete behavior
@ 2021-12-27 14:37 Noel Chiappa
2021-12-27 14:56 ` Will Senn
0 siblings, 1 reply; 6+ messages in thread
From: Noel Chiappa @ 2021-12-27 14:37 UTC (permalink / raw)
To: tuhs; +Cc: jnc
> From: Will Senn
> anything similar to modern behavior when handling the delete/backspace
> key where the character is deleted from the input and rubbed out? The
> default, like in v6/v7 for erase and kill is # and @. I can live with
> this, if I can't get it to do the rubout, because at least you can see
> the # in the input
I use ASCII 'backspace' (^H) on my V6, and it 'sort of' works; it doesn't
erase the deleted character on the screen, but if one then types corrected
characters, they overlay the deleted ones, leaving the corrected input. That
should work on everything later than V6.
The MIT PWB1 tty handler (link in a prior message) not only supported a 'kill
line' (we generally used '^U') which actually visibly deleted the old line
contents (on screen terminals, of course; on printing terminals you're
stuck), it also had suppport for '^R' (re-type line) and some other stuff.
Noel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] svr2 delete behavior
2021-12-27 14:37 Noel Chiappa
@ 2021-12-27 14:56 ` Will Senn
2021-12-27 23:52 ` John Cowan
0 siblings, 1 reply; 6+ messages in thread
From: Will Senn @ 2021-12-27 14:56 UTC (permalink / raw)
To: Noel Chiappa, tuhs
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]
On 12/27/21 8:37 AM, Noel Chiappa wrote:
> > From: Will Senn
>
> > anything similar to modern behavior when handling the delete/backspace
> > key where the character is deleted from the input and rubbed out? The
> > default, like in v6/v7 for erase and kill is # and @. I can live with
> > this, if I can't get it to do the rubout, because at least you can see
> > the # in the input
>
> I use ASCII 'backspace' (^H) on my V6, and it 'sort of' works; it doesn't
> erase the deleted character on the screen, but if one then types corrected
> characters, they overlay the deleted ones, leaving the corrected input. That
> should work on everything later than V6.
>
> The MIT PWB1 tty handler (link in a prior message) not only supported a 'kill
> line' (we generally used '^U') which actually visibly deleted the old line
> contents (on screen terminals, of course; on printing terminals you're
> stuck), it also had suppport for '^R' (re-type line) and some other stuff.
>
> Noel
Hi Noel, that's interesting.
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. 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.
Oh, the mysteries of terminal interaction. Add the fact that I'm using
Mac OS's Terminal, and no telling what could happen. I generally turn on
Option as Meta magic but I don't remap ^H as DEL :).
Will
[-- Attachment #2: Type: text/html, Size: 2249 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TUHS] svr2 delete behavior
2021-12-27 14:56 ` Will Senn
@ 2021-12-27 23:52 ` John Cowan
0 siblings, 0 replies; 6+ messages in thread
From: John Cowan @ 2021-12-27 23:52 UTC (permalink / raw)
To: Will Senn; +Cc: TUHS main list, Noel Chiappa
[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]
On Mon, Dec 27, 2021 at 9:56 AM Will Senn <will.senn@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.
>
[-- Attachment #2: Type: text/html, Size: 4059 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-12-27 23:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-27 0:31 [TUHS] svr2 delete behavior Will Senn
2021-12-27 1:24 ` Seth Morabito
2021-12-27 14:39 ` Will Senn
2021-12-27 14:37 Noel Chiappa
2021-12-27 14:56 ` Will Senn
2021-12-27 23:52 ` John Cowan
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).