stty erase '^?' in v7

stty erase '^?' in v7

[Will Senn]

Does anyone know why stty won't accept '^?' in v7? It will accept '^h', 
but then the shell expects ^h to "backspace". I am trying to get the 
delete key on my mac to do the backing up and it's '^?'. # isn't my 
favorite since it's used in C programs, but pressing CTRL-h to backup is 
a pain too. If you've read this far, I have three more questions:

1. How do you escape # in order to write a C program if # is the erase 
character in the terminal?
2. How do you enter a literal character in the v7 shell (I am used to 
CTRL-v CTRL-DEL to enter the delete character on other unices)?
3. Is there a way to echo the ascii value of a keypress in v7?

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

stty erase '^?' in v7

[Grant Taylor]

On 10/13/2017 08:59 PM, Will Senn wrote:
> 2. How do you enter a literal character in the v7 shell (I am used to 
> CTRL-v CTRL-DEL to enter the delete character on other unices)?

I don't know if it will help you or not, but I always dealt with this 
problem (allbeit on more modern unixes) via the following:

stty erase <Control>+<v><Backspace>

It seems as if the Control v tells the shell to insert the following key 
literally.  You may not need to do that if the shell is not interpreting ^h.



-- 
Grant. . . .
unix || die

stty erase '^?' in v7

[Random832]

On Fri, Oct 13, 2017, at 22:59, Will Senn wrote:
> Does anyone know why stty won't accept '^?' in v7? It will accept '^h', 
> but then the shell expects ^h to "backspace". I am trying to get the 
> delete key on my mac to do the backing up and it's '^?'. # isn't my 
> favorite since it's used in C programs, but pressing CTRL-h to backup is 
> a pain too. If you've read this far, I have three more questions:

First, you'd need to remove it as the *interrupt* character, which I
don't think the stty command in V7 can do, though the kernel supports it
with TIOCSETC. Signal characters are processed before input control
ones.

#include <sgtty.h>
struct sgttyb buf;
main() {
ioctl(1, TIOCSETC, "\3\34\21\23\4\377");
gtty(1, &buf);
buf.sg_erase = 0177;
buf.sg_kill = 025;
stty(1, &buf);
}

Also, it won't actually erase the character (unless your terminal
interprets an echoed ^? that way - to my knowledge only putty does) -
the crterase flag [and feature], which echoes space-backspace-space on
erase was added later than V7.

> 1. How do you escape # in order to write a C program if # is the erase 
> character in the terminal?

IIRC, it doesn't have effect on the first character of the line, which
is enough for C. Looking through the TTY driver, it looks like there's
code for backslash to escape it.

> 2. How do you enter a literal character in the v7 shell (I am used to 
> CTRL-v CTRL-DEL to enter the delete character on other unices)?

> 3. Is there a way to echo the ascii value of a keypress in v7?

You could probably put something together with stty raw, od, and sed q
(head didn't exist in v7, and you need *something* to cut things off
because ctrl-d won't work with stty raw), but it may be easier to figure
out what all your keys produce outside of your classic unix environment.

stty erase '^?' in v7

[Will Senn]

On 10/13/17 11:39 PM, Random832 wrote:
> On Fri, Oct 13, 2017, at 22:59, Will Senn wrote:
>> Does anyone know why stty won't accept '^?' in v7? It will accept '^h',
>> but then the shell expects ^h to "backspace". I am trying to get the
>> delete key on my mac to do the backing up and it's '^?'. # isn't my
>> favorite since it's used in C programs, but pressing CTRL-h to backup is
>> a pain too. If you've read this far, I have three more questions:
> First, you'd need to remove it as the *interrupt* character, which I
> don't think the stty command in V7 can do, though the kernel supports it
> with TIOCSETC. Signal characters are processed before input control
> ones.
>
> #include <sgtty.h>
> struct sgttyb buf;
> main() {
> ioctl(1, TIOCSETC, "\3\34\21\23\4\377");
> gtty(1, &buf);
> buf.sg_erase = 0177;
> buf.sg_kill = 025;
> stty(1, &buf);
> }
>
> Also, it won't actually erase the character (unless your terminal
> interprets an echoed ^? that way - to my knowledge only putty does) -
> the crterase flag [and feature], which echoes space-backspace-space on
> erase was added later than V7.
Yeeha, I actually understood your answer :). I didn't know that the 
delete key served a purpose, interrupt, which is good to know. The code 
works, but it's odd without the backing up and erasing, I may just stick 
with # and @.
>
>> 1. How do you escape # in order to write a C program if # is the erase
>> character in the terminal?
> IIRC, it doesn't have effect on the first character of the line, which
> is enough for C. Looking through the TTY driver, it looks like there's
> code for backslash to escape it.
Great answer, didn't even cross my mind, but of course a # at the start 
of a line is ignored, the backslash is obvious in retrospect too.
>> 2. How do you enter a literal character in the v7 shell (I am used to
>> CTRL-v CTRL-DEL to enter the delete character on other unices)?
>> 3. Is there a way to echo the ascii value of a keypress in v7?
> You could probably put something together with stty raw, od, and sed q
> (head didn't exist in v7, and you need *something* to cut things off
> because ctrl-d won't work with stty raw), but it may be easier to figure
> out what all your keys produce outside of your classic unix environment.

I'll go with easier :).

Thanks!

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

stty erase '^?' in v7

[Random832]

On Sat, Oct 14, 2017, at 01:03, Will Senn wrote:
> Yeeha, I actually understood your answer :). I didn't know that the 
> delete key served a purpose, interrupt, which is good to know. The code 
> works, but it's odd without the backing up and erasing, I may just stick 
> with # and @.

Well the obvious next step is to patch the kernel to do the backing up
and erasing.

I implemented this for myself once, but I've lost the code since then. I
*think* the right place is in tty.c, around line 489 (that's where it
currently handles the special echo rule for the kill character, anyway).
You'll just want to check for the erase character (and the same modes
that are checked for the kill character) and echo
backspace/space/backspace.

stty erase '^?' in v7

[Noel Chiappa]

    > From: Will Senn

    > 1. How do you escape # in order to write a C program if # is the erase 
    > character in the terminal?

"Use the source, Luke!" V7 is simple enough that it's pretty quick to find
the answers to things like this. E.g.

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/dev/tty.c>

will answer this question (in "canon()").

    > 3. Is there a way to echo the ascii value of a keypress in v7?

A quick look through tty.c suggests this doesn't exist in V7 - without running
a user program that puts the TTY in 'raw' mode and prints out what it
sees. Not sure if there is one off the rack, or if you'd have to whip up a
20-line program to do it.

       Noel

stty erase '^?' in v7

[Will Senn]

On 10/13/17 11:25 PM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > 1. How do you escape # in order to write a C program if # is the erase
>      > character in the terminal?
>
> "Use the source, Luke!" V7 is simple enough that it's pretty quick to find
> the answers to things like this. E.g.
>
>    http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/dev/tty.c>
>
> will answer this question (in "canon()").

Duh! I see it now... backslash. All that cooked and raw stuff is 
gobbledegook that I'll have to read up on.
>      > 3. Is there a way to echo the ascii value of a keypress in v7?
>
> A quick look through tty.c suggests this doesn't exist in V7 - without running
> a user program that puts the TTY in 'raw' mode and prints out what it
> sees. Not sure if there is one off the rack, or if you'd have to whip up a
> 20-line program to do it.
>
>         Noel

Maybe later :).

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

stty erase '^?' in v7

[Dave Horsfall]

On Sat, 14 Oct 2017, Noel Chiappa wrote:

>    > 3. Is there a way to echo the ascii value of a keypress in v7?
>
> A quick look through tty.c suggests this doesn't exist in V7 - without 
> running a user program that puts the TTY in 'raw' mode and prints out 
> what it sees. Not sure if there is one off the rack, or if you'd have to 
> whip up a 20-line program to do it.

Check out horsfall.org/keytest.c for something I wrote years ago.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

stty erase '^?' in v7

[Will Senn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

On 10/14/17 1:31 AM, Dave Horsfall wrote:
> On Sat, 14 Oct 2017, Noel Chiappa wrote:
>
>>    > 3. Is there a way to echo the ascii value of a keypress in v7?
>>
>> A quick look through tty.c suggests this doesn't exist in V7 - 
>> without running a user program that puts the TTY in 'raw' mode and 
>> prints out what it sees. Not sure if there is one off the rack, or if 
>> you'd have to whip up a 20-line program to do it.
>
> Check out horsfall.org/keytest.c for something I wrote years ago.
>
Works great on my macbook, not valid in V7, but that's ok, now at least 
I know what key value is being sent (0x7f).

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

stty erase '^?' in v7

[Dave Horsfall]

On Sat, 14 Oct 2017, Will Senn wrote:

>> Check out horsfall.org/keytest.c for something I wrote years ago.
>> 
> Works great on my macbook, not valid in V7, but that's ok, now at least 
> I know what key value is being sent (0x7f).

I never claimed that it was portable :-)  Going by the date, I'd say it 
was written for a CCI Power-6/32 (sorta SysV-ish) with some odd terminals 
that I had to incorporate into TERMINFO for our office software; I dimly 
recall posting it to aus.sources in case others could use it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

stty erase '^?' in v7

[Noel Chiappa]

    > From: Will Senn

    > I didn't know that the delete key served a purpose, interrupt

At MIT, the PWB1 (effectively) system that was standard at Tech Sq had had its
teletype driver completely re-written by the time I started using it, and that
was changed, so I never saw this IRL.

Recently, I needed a Unix to run under Ersatz-11, to talk to physical QBUS
-11's and download them over their console line, so I went with V6 (since I
had not at that point managed to recover the MIT system). Wow. Talk about
a rude awakening!

That was one of the things that was, ah, problematic - and in V6, there's no
way to change the interrupt character. (And no, I didn't feel like switching
to a later version!)

An even bigger problem was that in vanilla V6, there's _no way_ to do 8-bit
input _and_ output. Sheesh. I managed to fix that too, after a certain amount
of pain. (I missed a code path, or something like that, and it took me quite a
while to figure out why my fixes didn't work.)

    Noel

stty erase '^?' in v7

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

On Sat, Oct 14, 2017 at 8:52 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
> At MIT, the PWB1 (effectively) system that was standard at Tech Sq had had
> its
> ​ ​
> teletype driver completely re-written by the time I started using it, and
> that
> ​ ​
> was changed, so I never saw this IRL.
>
​Didn't Steve Zimmerman (of Zimmerman emacs) fame​ have his hand in this?
He hacked the MSCP tty handler heavily with a lot MIT features.

It was probably post the MIT job control stuff, but the tty handler I
remember and somewhat miss was a TENEX-like ^T feature that did a one line
ps of the jobs attached to your terminal.


> An even bigger problem was that in vanilla V6, there's _no way_ to do 8-bit
> input _and_ output. Sheesh.

Painful memories ... I remember seeing that early on too V5​ too and
thinking 'what a hack' as we had many glass TTY's with only an ASR33 on the
console back then.  And we were also trying to download binaries (to other
processors) so an 8-bit path was wanted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171014/ba90619b/attachment.html>

stty erase '^?' in v7

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

When Mike Muuss was working on the scheduler he added the ^T ala TENEX process list.    What was displayed changed over time.    I think I finally moved a “snippet” of the arg list over from the user structure to the proc structure so ^T would be able to get it.

stty erase '^?' in v7

[Don Hopkins]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

I loved ^T on Unix! I remember when somebody at UMCP added that feature to our 4.2 BSD Vax mimsy. The early version had the fun side-effect of being unregulated. Who added the one-second delay between responding to ^T so you couldn’t any longer hold down ^T with auto-repeat to drive the CPU load through the ceiling and watch as it got higher and higher trying to respond to all those ^T's? (Does that qualify as a Heizenbug, or is that a denial of self service?)

-Don


> On 14 Oct 2017, at 16:44, Ronald Natalie <ron at ronnatalie.com> wrote:
> 
> When Mike Muuss was working on the scheduler he added the ^T ala TENEX process list.    What was displayed changed over time.    I think I finally moved a “snippet” of the arg list over from the user structure to the proc structure so ^T would be able to get it.
> 

stty erase '^?' in v7

[Noel Chiappa]

    > From: Will Senn

    > All that cooked and raw stuff is gobbledegook that I'll have to read up
    > on.

The raw/cooked stuff isn't the source of the worst hair in the TTY driver;
that would be delays (on the output side), and delimiter processing (on the
input side).

The delays are for mechanical terminals, because they need delays after a
motion command (e.g. NL, CR, etc) before the next printing character is sent;
differing for different motion control commands, further complexified by the
current print head position - a Carriage Return from column 70 taking a lot
longer than one from column 10. The driver keeps track of the current column,
so it can calculate this! It does the delays by putting in the output queue a
chacter with the high bit set, and the delay in the low bits; the output start
routine looks for these, and does the delay.

On the input side, every time it sees a delimiter (NL, EOF), it inserts a 0xFF
byte in the input queue, and increments a counter to keep track of how many it
has inserted. I _think_ this is so that any given read call on a 'cooked'
terminal will return at most one line of input (although I don't know why they
don't just parse the buffer contents at read time - although I guess they need
the delimiter count so the read call will wait if there is not a complete line
there yet).

I should look and see how the MIT TTY driver (which also supported 8-bit input
and output) dealt with these...

    Noel