Anyone recommend a good terminal type?
John Nemeth
} On Wed, 15 Mar 2000, Stephen Borrill wrote:
}
} > I've installed ncurses-5.0 and dialog, but the default vt220 terminal
} > type defined in /etc/ttys does not support colour. Looking through
} > terminfo.src, I can't see any other obvious choices. I tried pc3, but it
} > doesn't have top-bit characters to display lines, etc.
}
} Actually, it's supposed to support color, but there's evidently some
Why? A real vt220 terminal doesn't have colour, so why should a
termcap/terminfo entry for a vt220 have colour definitions? Wouldn't
it be better to use a more appropriate terminal type?
}-- End of excerpt from Frederick Bruckman
Frederick Bruckman
You're right, it doesn't. T.E Dickey pointed out to me that, in
termcap, "Co#N" means colors, "co#N" means columns (case significant).
For terminfo, it's "colors#N". BTW, you can view the compiled terminfo
entries with "infocmp".
What was confusing me was that lynx linked with libslang _does_ do
color with the plain xterm and xterm-r6 entries. Evidently lynx sets
COLORTERM in the environment (for libslang), without regard to either
the terminfo or termcap entries.
Stephen Borrill
> On Jul 3, 8:58am, Frederick Bruckman wrote:
> } On Wed, 15 Mar 2000, Stephen Borrill wrote:
> }
> } > I've installed ncurses-5.0 and dialog, but the default vt220 terminal
> } > type defined in /etc/ttys does not support colour. Looking through
> } > terminfo.src, I can't see any other obvious choices. I tried pc3, but it
> } > doesn't have top-bit characters to display lines, etc.
> }
> } Actually, it's supposed to support color, but there's evidently some
>
> Why? A real vt220 terminal doesn't have colour, so why should a
> termcap/terminfo entry for a vt220 have colour definitions?
It shouldn't strictly.
> Wouldn't it be better to use a more appropriate terminal type?
Yes, it would. Question is/was what is a more appropriate terminal type?
After a bit of experimentation, I've found "color_xterm" to be successful
under X and the best I could find for the console was "screen". I've found
this to be usable with wscons as well as other terminal packages (e.g.
Simpterm32 on Windows). OK, it doesn't do the percentage counter in
reverse video when you use more, but that's nitpicking.
--
Dr. Stephen Borrill
Roger Brooks
>> Why? A real vt220 terminal doesn't have colour, so why should a
>> termcap/terminfo entry for a vt220 have colour definitions?
>
>It shouldn't strictly.
But many vt220 emulators do have colour support (and I suspect real
VT220 terminals are a bit rare these days). And a properly-constructed
ANSI escape sequence parser should silently ignore any SGR parameters
which it doesn't understand. Certainly a Wyse-185, which is the nearest
we have to a hardware VT220 does.
Roger
------------------------------------------------------------------------------
Roger Brooks (Systems Programmer), | Email: R.S.B...@liv.ac.uk
Computing Services Dept, | Tel: +44 151 794 4441
The University of Liverpool, | Fax: +44 151 794 4442
PO Box 147, Liverpool L69 3BX, UK |
------------------------------------------------------------------------------
Scott Telford
entry, complete with colour support, specifically for wscons in
{VT100,Sun} emulation mode? IMHO, there's no point implementing colour
(or anything else above strict {VT100,Sun} emulation) unless there's an
appropriate termcap definition which allows you to use it (apart from
random ones like "screen" which just happen to kinda sorta work).
--
Scott Telford "If 386BSD had been available when
Edinburgh Parallel Computing Centre I started on Linux, Linux would
University of Edinburgh, EH9 3JZ, UK. probably never had happened."
s.te...@ed.ac.uk +44 131 650 5978 - Linus Torvalds
Andy Doran
> Doesn't it make sense to create a "wscons{vt,sun}" (or whatever) termcap
> entry, complete with colour support, specifically for wscons in
> {VT100,Sun} emulation mode? IMHO, there's no point implementing colour
> (or anything else above strict {VT100,Sun} emulation) unless there's an
> appropriate termcap definition which allows you to use it (apart from
> random ones like "screen" which just happen to kinda sorta work).
See "wsvt25" and "wsvt25m". I don't think there's a "wsvt" entry. These
don't have color defs... yet.
__________________________________________________
Do You NetBSD!?
Talk to your friends online with NetBSD OS!.
http://www.netbsd.org
Simon Burge
> But many vt220 emulators do have colour support (and I suspect real
> VT220 terminals are a bit rare these days).
Hrmph! A real vt220 is still the console for my home serial based
machines. I really must upgrade to one of those new-fangled vt420's
one day... ;)
Simon.
David Brownlee
> Hrmph! A real vt220 is still the console for my home serial based
> machines. I really must upgrade to one of those new-fangled vt420's
> one day... ;)
You don't want that - that would give you the ability to
have an escape key that sends a single escape character!
(Memories os using vi with CTRL+[ :)
Ob on-topic-comment:
If we want to use wsvt or similar as our default terminal type
at some point then we need to ensure its in the master terminfo
database now so at least those systems (linux etc) that keep up
to date will have the right defintion for when you rlogin from
an NetBSD's machine's console. (s/rlogin/ssh/ etc)
David/absolute
Greg A. Woods
> Subject: Re: Anyone recommend a good terminal type?
>
> But many vt220 emulators do have colour support (and I suspect real
> VT220 terminals are a bit rare these days).
Perhaps there should be a generic "vt220 plus colour" terminal type
definition, but regardless there must be a plain "vt220" terminal type
that does not claim the terminal supports colour.
> And a properly-constructed
> ANSI escape sequence parser should silently ignore any SGR parameters
> which it doesn't understand. Certainly a Wyse-185, which is the nearest
> we have to a hardware VT220 does.
Indeed, but that's not the point. A "termcap" (or "terminfo") entry
defines the capabilities of the terminal. If it claims colour is
available and the application tries to use colour instead of something
more useful under the circumstances, like bold, dim, and underline,
etc. then the user will not be happy. Personally I'd be more than just
unhappy -- I'd be very angry and be cursing six ways to Sunday until I
managed to edit the offending crap out of the broken terminal
definition.
As for the authors of the terminal emulators (and in particular the
eumlators used for the OS consoles of machines like PCs), they should be
extremely careful in thinking about which base terminal type to choose
to emulate, which features to leave out (if any), and just as
importantly which new features they might think to add to enhance the
base terminal type (if any).
Personally I'd be extremely happy if the standard MI console emulator
for NetBSD were to take a lesson from Kermit and *exactly* emulate a
real terminal with no extensions at all whatsoever, with 100% bug-for-
bug compatability. If that's a vt420, or just a vt220, or even just a
vt100, that would be just fine by me. If several types are possible
then all the better, just so long as they are *perfect* emulations. Of
course that does mean being able to go into "setup" mode to tweak the
terminal's behaviour (at least for those parts that affect the screen
and keyboard, etc.), just like with a real terminal. There's nothing
more painful and frustrating than a unique terminal "emulation" on a
console that doesn't 100% match any real terminal from a
terminfo/termcap point of view, especially when what's really there is
so vaguely documented that it takes a weeks worth of experimentation and
fiddling to write a proper terminfo/termcap entry (not as much of a
problem of course when you have the source). Do it right, or don't do
it at all.
As for the issue of having a proper terminal type on a remote system
that I might access from a console emulator, well at least with DEC's
original terminals I have some assurance that using a "lesser" termcap
definition for an older real terminal on a more capable terminal will
still work OK so long as the termcap I choose doesn't depend on some bug
in the original terminal that's been fixed in the newer and more
advanced one.
These days though I can usually depend on being able to run an xterm
somewhere and almost 99% of the time the xterm terminal definition on
the target host is close enough within spec that at least highlighting
works properly and emacs/vi function without the need for too many
screen refreshes.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
der Mouse
> terminal.
Well, I'd say "describes"; it's the terminal itself that *defines* its
capabilities.
> As for the authors of the terminal emulators (and in particular the
> eumlators used for the OS consoles of machines like PCs), they should
> be extremely careful in thinking about which base terminal type to
> choose to emulate, which features to leave out (if any), and just as
> importantly which new features they might think to add to enhance the
> base terminal type (if any).
Of course, there's no particular reason why they have to emulate any
particular existing "real" terminal. When I did my terminal emulator,
I did exactly that: ignored all "real" terminals. (Later, I added an
emulation module designed around ANSI X3.41/X3.64, to which I added
various DEC extensions, producing a very serviceable VT100 emulator.)
> Personally I'd be extremely happy if the standard MI console emulator
> for NetBSD were to take a lesson from Kermit and *exactly* emulate a
> real terminal with no extensions at all whatsoever, with 100%
> bug-for-bug compatability.
I doubt that's really possible in any significant number of cases. If
nothing else, the keyboard will be different.
> If several types are possible then all the better, just so long as
> they are *perfect* emulations.
Note also that true bug-for-bug emulation will more or less require the
ROMed code from the original terminal, since AFAIK nobody knows what
bugs may lurk in corner cases. (I'm also not sure full bug-for-bug
compatability is a good thing; is it necessarily desirable to have the
emulated terminal crash when - and in the same way that - the real one
would?)
> There's nothing more painful and frustrating than a unique terminal
> "emulation" on a console that doesn't 100% match any real terminal
> from a terminfo/termcap point of view,
I don't think I've yet seen a terminal emulation that 100% matches the
real thing. If nothing else the keybaord layouts are always wrong.
(Yes, this can matter, if some program assumes things about the
keyboard geometry.) Even with respect to output only, I've never seen
an emulator that was a perfect emulation. Even my own, the closest
thing it emulates is something in the VT-xxx line, and it supports some
of X3.64 that AFAIK none of the VT-xxx terminals do, and definitely
supports some DCS sequences the rael things don't.
With respect to the specific case of an i386 console, I suspect that
you'll find very few real 25-line terminals, and also suspect you'll
find comparatively few people willing to give up that 25th line for the
sake of your desire for an unattainable perfect emulation of some real
thing. (As opposed to terminals which have a 25th line in hardware but
make it accessible only as a "status" line of some sort, which of
course would be emulable but would lose that line as far as most
programs are concerned.)
der Mouse
mo...@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Greg A. Woods
> Subject: Re: Anyone recommend a good terminal type?
>
> > terminal.
>
> Well, I'd say "describes"; it's the terminal itself that *defines* its
> capabilities.
Yes, that's a better term....
> Of course, there's no particular reason why they have to emulate any
> particular existing "real" terminal. When I did my terminal emulator,
> I did exactly that: ignored all "real" terminals. (Later, I added an
> emulation module designed around ANSI X3.41/X3.64, to which I added
> various DEC extensions, producing a very serviceable VT100 emulator.)
For console emulators there are very strong desires to emulate a common
terminal well enough that it doesn't annoy anyone who uses the console
to remotely access some other system that's likely to know how to speak
to this "common" terminal type.
> Note also that true bug-for-bug emulation will more or less require the
> ROMed code from the original terminal, since AFAIK nobody knows what
> bugs may lurk in corner cases.
In the case of any well known "classic" terminal the bugs that are
important from a terminfo/termcap point of view are all very well known
by now (though sometimes their exact nature is lost in folklore and/or
obscure bits of code in various libcurses implementations).
Certainly for a relatively new, and/or relatively rare terminal the
bugs might not all be known, perhaps not even well enough to create a
true full-function terminfo/termap entry..
> (I'm also not sure full bug-for-bug
> compatability is a good thing; is it necessarily desirable to have the
> emulated terminal crash when - and in the same way that - the real one
> would?)
In some cases it's absolutely necessary if you want some applications to
behave properly. Unix applications are generally very forgiving and
unless the "bug" is a really annoying quirk the occasional full-screen
refresh is enough to struggle through.
What's important to keep in mind of course is that bugs in this sense
are only important from a terminfo/termcap point of view -- i.e. do they
affect the way an application using such capabiilties databases will
operate. If a bug has been either dealt with by a special quirk entry
or by changing or omitting what would otherwise be a correct item
according to the documentation or some expected reference standard then
the emulation must function correctly when driven by an application
expecting to have to use that quirk (or changed item, etc.). Of course
it's also important that the emulation not require its own quirks,
changes, or omissions in the capabilities description either or else it
too becomes a distinct terminal type.
> > There's nothing more painful and frustrating than a unique terminal
> > "emulation" on a console that doesn't 100% match any real terminal
> > from a terminfo/termcap point of view,
>
> I don't think I've yet seen a terminal emulation that 100% matches the
> real thing.
MS-Kermit made invalid claims about their emulation for a long time but
they finally did get it right so far as I could tell.... Early versions
of it did require their own terminfo/termcap entries but more recent
versions have been able to use the "real" entries without even a glitch.
> If nothing else the keybaord layouts are always wrong.
The keyboard layout is not normally important -- what's important is
that keys with the same label mean the same thing to the application.
> (Yes, this can matter, if some program assumes things about the
> keyboard geometry.)
Well, sort of, yes, that's true, though generally the cases I'm familiar
with do not involve any keys that generate complex sequences (i.e. are
simply using alphanumeric keys).
> Even with respect to output only, I've never seen
> an emulator that was a perfect emulation.
I've directly compared some version of MS-Kermit (post 3.x) to my real
VT100 with all available test suites and many applications and it lives
up to its claims of 100% perfect bug-for-bug emulation.
> With respect to the specific case of an i386 console, I suspect that
> you'll find very few real 25-line terminals, and also suspect you'll
> find comparatively few people willing to give up that 25th line for the
> sake of your desire for an unattainable perfect emulation of some real
> thing. (As opposed to terminals which have a 25th line in hardware but
> make it accessible only as a "status" line of some sort, which of
> course would be emulable but would lose that line as far as most
> programs are concerned.)
Indeed most of the real "24x80" terminals I have actually display at
least 25 lines physically. On some you can in fact use that 25th line
for data though usually it's dedicated to being a status line as you
say. In fact a quick search through the NetBSD termcap file for real
terminals (i.e. after eliminating the emulators) reveals quite a few
25-line terminals. There are several terminals that can use the 25th
line for data and that are widely enough known, at least in Unix
circles, that they would make a great basis for an emulator for a PC
console. Indeed almost every Wyse terminal since the wy60 can do that,
as can at least one of the AT&T models I have.
Aaron J. Grier
> I'd be very angry and be cursing six ways to Sunday until I managed to
> edit the offending crap out of the broken terminal definition.
there's a reason it's called "curses." ;)
--
Aaron J. Grier | "Not your ordinary poofy goof." | agr...@poofygoof.com
"Time Correct function allows automatically correcting slight variation
of your key touching manner." -- Roland MSQ-700 manual
John Nemeth
} Subject: Re: Anyone recommend a good terminal type?
}
} >> Why? A real vt220 terminal doesn't have colour, so why should a
} >> termcap/terminfo entry for a vt220 have colour definitions?
} >
} >It shouldn't strictly.
}
Not as rare as you might think. I have several real DEC terminals
(including a VT220). Other people on the list, have also mentioned
having them.
} ANSI escape sequence parser should silently ignore any SGR parameters
} which it doesn't understand. Certainly a Wyse-185, which is the nearest
Not the point. A real terminal can do anything it wants with an
undefined sequence. Furthermore, an application using it would expect
the terminal to behave in a certain way which it won't, and may use it
in preference to something that would be much more suitable, such as
inverse, highlight, underline, flash, etc.
}-- End of excerpt from Roger Brooks
John Nemeth
}
} With respect to the specific case of an i386 console, I suspect that
} you'll find very few real 25-line terminals, and also suspect you'll
} find comparatively few people willing to give up that 25th line for the
} sake of your desire for an unattainable perfect emulation of some real
} thing. (As opposed to terminals which have a 25th line in hardware but
} make it accessible only as a "status" line of some sort, which of
} course would be emulable but would lose that line as far as most
} programs are concerned.)
I would actually very much like to have an emulated status line.
MS-Kermit has it, and it is a feature that I miss. I typically ran
"sysline" to keep information in the status line. Other programs were
capable of using it as well.
}-- End of excerpt from der Mouse
Grey Wolf
# On Jul 15, 6:31am, der Mouse wrote:
# }
# } With respect to the specific case of an i386 console, I suspect that
# } you'll find very few real 25-line terminals, and also suspect you'll
# } find comparatively few people willing to give up that 25th line for the
# } sake of your desire for an unattainable perfect emulation of some real
# } thing. (As opposed to terminals which have a 25th line in hardware but
# } make it accessible only as a "status" line of some sort, which of
# } course would be emulable but would lose that line as far as most
# } programs are concerned.)
#
# I would actually very much like to have an emulated status line.
# MS-Kermit has it, and it is a feature that I miss. I typically ran
# "sysline" to keep information in the status line. Other programs were
# capable of using it as well.
Oh, yeah! Sysline! I remember that one.
Used to use it regularly on LSI adm5s with the RG512 graphics boards
in them. Had the escape sequence for the status line print in graphics
mode at the very bottom of the screen.
#
# }-- End of excerpt from der Mouse
#
--*greywolf;
--
OpenSource is NOT exclusive to Linux. Explore your options!