On Tue, 3 Nov 1998, Steve Revilak wrote:

Pc is a gettytab entry, not a termcap entry. It's main purpose is to
set up the line _before_ you login. On the console, vt220 works fine
for me; what is it that works strangely for you? This is what I have
in my {.bash_login, .login}:

eval `command tset -s vt220`
stty crt -istrip

The -istrip give you the eight-bit characters.

> I've got a question regarding the behavior of ttye0 (the basic command
> line environment).  I'd like to know if it's possible to allow it to
> 'understand' more keyboard characters than it does by default.  For
> example Ctrl-SPC and/or Ctrl-@ (ie., the 'set-mark' keys
> used by editors like emacs and jove).  Defining a Meta key would be
> even sweeter....
> 
> In an Xwindow environment, these are recognized perfectly well, so I'd
> think that the capability exists.  Would this be a matter of changing
> /etc/ttys, /etc/gettytab, or is this something that's built into the
> kernel, thus requiring a custom compilation.
> 
> ttye0 seems to be vt100...reasoning that by the fact that if $TERM is
> set to anythin else, certain things tend to work strangely--arrow keys
> for example.
> 
> Looks like 'getty Pc' is used for the console.  Any recomendations for
> another entry? (Having a zillion in termcap, I'm asking first). I
> though about doing 'printenv' under X to get the 'xterm'
> settings..though I can see potential for problems there as well.
> 
> I know there's the thought of 'Why not just run X or dt?'  My problem
> is the need to use hfsutils on a frequent basis to get at the stuff on
> my machines hfs drive.  If either X or dt is running, using any of the
> hfsutils runs me smack into a kernel panic....

In response to you're other post, yes, it did that to me, too. Quadra
630/36M. Last time I tried it was with hfsutils-3.2.2, built against a
sup from August, this year.