Subject: Re: PCVT/virtual consoles
To: Charles M. Hannum <firstname.lastname@example.org>
From: Brian Buhrow <email@example.com>
Date: 05/08/1995 17:38:15
It strikes me that there are two such user level programs that already
do the work necessary to make multiple terminal sessions on one terminal.
The first, window, is distributed with netbsd out of the box and allows you
to define up to 9 windows, each of which can cover any portion of the
screen. I use 8 half screen windows, with one full screen window for those
applications which work best under full 23 line displays. Window's primary
drawback is that it uses a proprietary (unique) termcap entry to describe
its terminal capabilities. This has the disadvantage that logging into
other machines via one of your windows can create terminal capability
confusion. There are work arounds and anyone interested can mail me for
The second program, screen, is a GNU thing which allows you to have 10
VT100 terminal screens on one terminal. It uses the termcap database to
convert your non-vt100 terminal into 10 vt100 terminal sessions. (It can
be used as a terminal protocol translator if you so choose.) In any case,
it has the primary disadvantage, in my view, that it does not allow you to
split the screen into "windows".
I use "window" on a daily basis and have done so for over 5 years.
It works great, is a great program, and I highly recommend it.
On May 8, 7:38am, "Charles M. Hannum" wrote:
} Subject: Re: PCVT/virtual consoles
} Personally I'd like multiple text consoles on the vt320 on one
} of my sparcs - it would be nice if the virtual terminals support
} was architecture independant.
} Great idea! I suggest you write a user-level application to do it!
} Getting the multiple X server support to be architecture independant
} I would consider another (worthwhile) issue, but shouldn't basic pcvt
} support be generalised first?
} No offense intended to Hellmuth, but pcvt is *not* well enough
} abstracted or written that I want to standardize on it. It's also
} pretty clear to me that it's not the right solution to the problem.
>-- End of excerpt from "Charles M. Hannum"