Basic vt100 console "noisy
Date: Wed, 20 Nov 2019 20:14:24 -0500 From: Jason Mitchell To: Clay Daniels Subject: Re: Basic vt100 console "noisy" I wanted to share what Jason sent me privately: "Clay, The extra tty's are accessible by Control-Alt-F2 through F4 if they're enabled (I think they are by default). Jason M." This is good information, which I did not know. I tried it with my older 2014 HP Pavilion that I'm trying to load NetBSD on, and this did not seem to work. However, I was having the same trouble with "noisy system messages" on my OpenBSD install on my new home-built Ryzen 7 3700x machine and it worked like MAGIC! Eliminated the noise entirely, and like he says there are three of these extra tty logins. CTL-ALT-F(1,2,OR 3) What I think I need to do is find room on my new machine for NetBSD:-;
Re: [netbsd-users] Re: Basic vt100 console "noisy"
On Fri, 22 Nov 2019, at 07:40, Rhialto wrote: : : > If you have a serial terminal at hand, it is always fun to try. I > operated a DEC Alpha with a serial console, even though it had display > hardware. I had a real Wyse terminal running in vt52 emulation mode as a console for a number of years until the power supply blew and I was quoted an outrageous price to replace it ... while it was running it was awesome to have that in the corner of the room - with screen running it was as functional as a regular pseudo-terminal ... Regards, Malcolm -- Malcolm Herbert m...@mjch.net
Re: Basic vt100 console "noisy"
On Thu 21 Nov 2019 at 00:21:27 +, Clay Daniels wrote: > Thanks so much Johnny & Olaf. The other consoles look promising. Does this > relate to the NetBSD Guide Chap 3.9 Disk Prep process for selecting > bootblocks? > > http://www.netbsd.org/docs/guide/en/chap-exinst.html#exinst-disk-preparation-process Sort of. In the sense that if you select a serial console, the green output goes to the serial port and not to the VGA screen. Johnny is correct in pointing out that perhaps I should not have called these switchable virtual terminals "console", but people are sloppy and the thing is called "wscons" which makes it harder. > I have just been selecting the BIOS console, and maybe I should select one > of the serial ports, or option g : Use existing bootblocks ? > > I think the console selection is the clue. I will play with this and try a > fresh install with one of the serial ports, like com0. You can even change the console in an existing installation (although personally I've never needed it). Look at the manual page of installboot, and the option -o console=... . You can also (for the current boot only) set the console from the boot loader. See manual page boot(8), command "consdev". If you have a serial terminal at hand, it is always fun to try. I operated a DEC Alpha with a serial console, even though it had display hardware. > Clay -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Basic vt100 console "noisy"
On 2019-11-20 23:20, Rhialto wrote: On Wed 20 Nov 2019 at 21:44:56 +0100, Johnny Billquist wrote: You might want to look at the syslogd configuration then? That might be one source of messages being printed. Furthermore, they are only printed to the first console. If you enable more (ttyE[0-3] in /etc/ttys I think, and wscons=YES in /etc/rc.conf), you can login on other consoles that are quiet. Well, those are not even the console. They might appear on the same physical screen, but from the OS point of view, they are different terminals. But yes, you have a good point there. Switch to another terminal, and you should also not be bothered by output to the console. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Basic vt100 console "noisy"
On Wed, 20 Nov 2019, Rhialto wrote: Date: Wed, 20 Nov 2019 23:20:40 +0100 From: Rhialto To: Johnny Billquist Cc: Clay Daniels , netbsd-users , Scott Bennett Subject: Re: Basic vt100 console "noisy" On Wed 20 Nov 2019 at 21:44:56 +0100, Johnny Billquist wrote: You might want to look at the syslogd configuration then? That might be one source of messages being printed. Furthermore, they are only printed to the first console. If you enable more (ttyE[0-3] in /etc/ttys I think, and wscons=YES in /etc/rc.conf), you can login on other consoles that are quiet. Thanks so much Johnny & Olaf. The other consoles look promising. Does this relate to the NetBSD Guide Chap 3.9 Disk Prep process for selecting bootblocks? http://www.netbsd.org/docs/guide/en/chap-exinst.html#exinst-disk-preparation-process I have just been selecting the BIOS console, and maybe I should select one of the serial ports, or option g : Use existing bootblocks ? I think the console selection is the clue. I will play with this and try a fresh install with one of the serial ports, like com0. Clay -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" clays.sh...@sdf.org SDF Public Access UNIX System - http://sdf.org
Re: Basic vt100 console "noisy"
On Wed 20 Nov 2019 at 21:44:56 +0100, Johnny Billquist wrote: > You might want to look at the syslogd configuration then? That might be one > source of messages being printed. Furthermore, they are only printed to the first console. If you enable more (ttyE[0-3] in /etc/ttys I think, and wscons=YES in /etc/rc.conf), you can login on other consoles that are quiet. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Basic vt100 console "noisy"
On 2019-11-20 21:39, Clay Daniels wrote: I'm having real trouble with my console window if I'm not running an X window. There is constant system "chatter" about devices and such that interupts what I'm trying to do. The worst problem is when I try to use vi and it interupts me in mid-line. I realize it may be my old machine, a 2014 HP Pavilion23 All-in-one. But I have allocated the whole disk to NetBSD, and would like to get it to work. I'm going to try a re-install, but will hold off to see if anyone has any suggestions on how to "quiet down" the console "chatter". You might want to look at the syslogd configuration then? That might be one source of messages being printed. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Basic vt100 console "noisy"
I'm having real trouble with my console window if I'm not running an X window. There is constant system "chatter" about devices and such that interupts what I'm trying to do. The worst problem is when I try to use vi and it interupts me in mid-line. I realize it may be my old machine, a 2014 HP Pavilion23 All-in-one. But I have allocated the whole disk to NetBSD, and would like to get it to work. I'm going to try a re-install, but will hold off to see if anyone has any suggestions on how to "quiet down" the console "chatter". Thanks, Clay clays.sh...@sdf.org SDF Public Access UNIX System - http://sdf.org
Re: Why is TERM=vt100 on the console?
Sorry for the later answer. This mail got sorted wrong in my inbox. And sorry if I put another log on a fire that had all but dies out, but I think my comments are important here... On 2018-09-14 10:52, m...@netbsd.org wrote: Gotta drop my pumpkin spice latte and show off my favourite terminal program, the fish shell. It doesn't even work in vt100, I assume because they thought nobody would be using it in 2018. I assume by "terminal program", you mean a program that runs in a terminal, and not a program that implements a terminal. I hadn't seen fish before, but I decided to check it out because of your claim, and I am happy to report that fish uses curses for all its terminal handling, and it works just fine in a vt100. Why didn't you try it before claiming it didn't? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Why is TERM=vt100 on the console?
On Sat, Sep 15, 2018 at 12:15:55AM +0200, Johnny Billquist wrote: > And the wording you use make me feel that you are person to is easy to > dislike. Why are you trying to abuse people and act a jerk? Fair 'nuff. While I am explicitly disinterested in winning any popularity contests, I shouldn't have argued in such a disrespectful way. I assume there's some console correctness he's arguing for. Sorry, uwe.
Re: Why is TERM=vt100 on the console?
On Fri, Sep 14, 2018 at 11:32:53PM +, Valery Ushakov wrote: > Or even better, change console to off and ttyE0, which is already set > to wsvt25, to on. This is the default e.g. on macppc (of the ports > that I use). Yes, that is what I'll make sysinst do (unless you installed serial console boot blocks, or would have done that by default). Side note: *all* of my amd64 machines I got last year and this year do have com ports and I use them as console - exception: the notebooks. (But yes, none of them had the internal connector wired to the back panel when shiped.) I also have no issue using serial consoles with TERM=wsvt25, as it is not too far away from the proper "xterm" I usually change it to. Maya: please calm down and recheck when I'm done (should be soon). Martin
Re: Why is TERM=vt100 on the console?
Valery Ushakov wrote: > Anyway, as I said, if you know you will always/mostly use wscons, > just go and change the value in ttys. Or even better, change console to off and ttyE0, which is already set to wsvt25, to on. This is the default e.g. on macppc (of the ports that I use). -uwe
Re: Why is TERM=vt100 on the console?
m...@netbsd.org wrote:
> On Fri, Sep 14, 2018 at 11:08:29AM +, Valery Ushakov wrote:
>> m...@netbsd.org wrote:
>>
>> > Every time we have this discussion someone ends up saying that yes,
>> > everything being terrible and not supporting anything modern is a
>> > great default. they like it that way.
>>
>> /etc/ttys uses wsvt25 on all ttyE* for a long long time. It only uses
>> vt100 for console, which may be a serial console, so vt100 is a safe
>> default there. If you know you don't use serial console you can edit
>> 1 (one) line in ttys. Do you really think this is "terrible"?
>
> etc.sparc64/ttys:console"/usr/libexec/getty suncons"wsvt25 on
> secure
>
> Why is sparc{,64} exempt from having shitty defaults? because people
> who use it don't have to ask netbsd-users if they happen to use
> sufficiently shitty hardware to justify shitty defaults?
This is funny in a way, b/c on sparc it's very easy to switch between
serial console and wscons and I did it all the time when I still
hacked on sparc regularly. When I had free monitor/keyboard I'd use
them, when that monitor/keyboard were hooked up to something else (or
when copy-pasting text to/from console was convenient, e.g. when
digging through OFW), I'd use serial.
vt100 is a *perfect* default for this (especially on sparc, that's why
it's funny) b/c terminal emulators you'd use to access serial are
predominantly vt-compatible. It also works with wscons b/c wscons use
vt-compatible emulattion by default too. Yes, TERM=vt100 will not
descibe everything that wscons can do (like colors), but it will work.
This is what defaults are for. They are meant to work in most cases.
If i really needed colors on wscons, they were just a single
"TERM=wsvt25" command away.
Anyway, as I said, if you know you will always/mostly use wscons, just
go and change the value in ttys. This is what that file is for. In
the dark times when real CRT terminals were a thing that was what you
did when you hooked up a terminal to the system, you'd go and edit
ttys. B/c you might have vt220 connected and then you have to move it
elsewhere, but then you hook up a Wyse terminal to that port, etc,
etc.
Yes, I get it, these days most people don't quite grasp why TERM is
even there. Yes, on x86 where serial consoles are not normally used
on consumer machines there's an argument to be made for wsvt25 to be
the default for console (b/c people who actually use serial console on
x86 have enough clue to edit ttys to reflect the configuration of
their system). But I'd say it's not the best strategy on your part to
open this discussion with an argument that has "shit" in every
sentence and with the technical side of the argument being,
effectively, "I can't edit one line in one file once" ("because I have
paws" as cat memes popular here often say).
-uwe
Re: Why is TERM=vt100 on the console?
On Sat, Sep 15, 2018 at 12:15:55AM +0200, Johnny Billquist wrote:
> On 2018-09-14 22:07, m...@netbsd.org wrote:
> > On Fri, Sep 14, 2018 at 11:08:29AM +, Valery Ushakov wrote:
> > > m...@netbsd.org wrote:
> > >
> > > > Every time we have this discussion someone ends up saying that yes,
> > > > everything being terrible and not supporting anything modern is a
> > > > great default. they like it that way.
> > >
> > > /etc/ttys uses wsvt25 on all ttyE* for a long long time. It only uses
> > > vt100 for console, which may be a serial console, so vt100 is a safe
> > > default there. If you know you don't use serial console you can edit
> > > 1 (one) line in ttys. Do you really think this is "terrible"?
> >
> > etc.sparc64/ttys:console"/usr/libexec/getty suncons"wsvt25 on secure
> >
> > Why is sparc{,64} exempt from having shitty defaults? because people who
> > use it don't have to ask netbsd-users if they happen to use sufficiently
> > shitty hardware to justify shitty defaults?
> >
> > x86 hardware doesn't even have console 99% of the time!
> > sysinst isn't a solution because sysinst barely supports amd64.
>
> If you don't even have a console, why are you complaining?
Because the default terminal on amd64 is the vt100 console one.
Re: Why is TERM=vt100 on the console?
On 2018-09-14 22:07, m...@netbsd.org wrote:
On Fri, Sep 14, 2018 at 11:08:29AM +, Valery Ushakov wrote:
m...@netbsd.org wrote:
Every time we have this discussion someone ends up saying that yes,
everything being terrible and not supporting anything modern is a
great default. they like it that way.
/etc/ttys uses wsvt25 on all ttyE* for a long long time. It only uses
vt100 for console, which may be a serial console, so vt100 is a safe
default there. If you know you don't use serial console you can edit
1 (one) line in ttys. Do you really think this is "terrible"?
etc.sparc64/ttys:console"/usr/libexec/getty suncons" wsvt25 on secure
Why is sparc{,64} exempt from having shitty defaults? because people who
use it don't have to ask netbsd-users if they happen to use sufficiently
shitty hardware to justify shitty defaults?
x86 hardware doesn't even have console 99% of the time!
sysinst isn't a solution because sysinst barely supports amd64.
If you don't even have a console, why are you complaining?
And the wording you use make me feel that you are person to is easy to
dislike. Why are you trying to abuse people and act a jerk?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Re: Why is TERM=vt100 on the console?
On Fri, Sep 14, 2018 at 11:08:29AM +, Valery Ushakov wrote:
> m...@netbsd.org wrote:
>
> > Every time we have this discussion someone ends up saying that yes,
> > everything being terrible and not supporting anything modern is a
> > great default. they like it that way.
>
> /etc/ttys uses wsvt25 on all ttyE* for a long long time. It only uses
> vt100 for console, which may be a serial console, so vt100 is a safe
> default there. If you know you don't use serial console you can edit
> 1 (one) line in ttys. Do you really think this is "terrible"?
etc.sparc64/ttys:console"/usr/libexec/getty suncons"wsvt25 on secure
Why is sparc{,64} exempt from having shitty defaults? because people who
use it don't have to ask netbsd-users if they happen to use sufficiently
shitty hardware to justify shitty defaults?
x86 hardware doesn't even have console 99% of the time!
sysinst isn't a solution because sysinst barely supports amd64.
Re: Why is TERM=vt100 on the console?
m...@netbsd.org wrote: > Every time we have this discussion someone ends up saying that yes, > everything being terrible and not supporting anything modern is a > great default. they like it that way. /etc/ttys uses wsvt25 on all ttyE* for a long long time. It only uses vt100 for console, which may be a serial console, so vt100 is a safe default there. If you know you don't use serial console you can edit 1 (one) line in ttys. Do you really think this is "terrible"? -uwe
Re: Why is TERM=vt100 on the console?
On Fri, Sep 14, 2018 at 08:30:48AM +, m...@netbsd.org wrote: > Every time we have this discussion someone ends up saying that yes, > everything being terrible and not supporting anything modern is a great > default. they like it that way. I tried to fix it in 2012 (for PR 10127). Maybe at that time I did not try hard enough, but I will test and fix it now. Note that we get it right in our install media, by testing the console actually in use against /dev/ttyE*. I thought this would propagate into the installed system, but if not, I'll make it so. Martin
Re: Why is TERM=vt100 on the console?
Every time we have this discussion someone ends up saying that yes, everything being terrible and not supporting anything modern is a great default. they like it that way.
Re: Why is TERM=vt100 on the console?
Date:Thu, 13 Sep 2018 12:55:44 +0200 From:Martin Husemann Message-ID: <20180913105544.gb23...@mail.duskware.de> | On Thu, Sep 13, 2018 at 12:47:59PM +0200, Benny Siegert wrote: | > export TERM=wsvt25 | > | > makes a number of console applications display colors. | > | > Why is this not the default? | | It should be the default for newer installs, but it is not changed on | updates. And for why, vt100 is more likely to work than anything else that could be picked aside from "dumb" - including for serial consoles (not everyone uses a wscons, even on amd64 installs). And also, most apps that use colours (terminal colours, where the supported choices are usually quite limited) are *ugly* and having them supressed is no loss at all! kre
Re: Why is TERM=vt100 on the console?
On Thu, Sep 13, 2018 at 12:47:59PM +0200, Benny Siegert wrote: > export TERM=wsvt25 > > makes a number of console applications display colors. > > Why is this not the default? It should be the default for newer installs, but it is not changed on updates. Martin
Why is TERM=vt100 on the console?
Hi, this is something which has baffled me for a while. On an amd64 system at least, when you log in on a text console, $TERM is set to vt100. This gives a barely functional terminal with notably no support for colors. The wsvt25 terminal type corresponds much better to, well, the wsvt driver, so a simple export TERM=wsvt25 makes a number of console applications display colors. Why is this not the default? -- Benny
Re: vt100
On 2017-12-30 19:40, Kamil Rytarowski wrote: On 30.12.2017 19:25, Thomas Dickey wrote: On Sat, Dec 30, 2017 at 01:09:02PM -0500, Thomas Dickey wrote: On Sat, Dec 30, 2017 at 06:38:16PM +0100, Kamil Rytarowski wrote: On 30.12.2017 17:41, Thomas Dickey wrote: On Sat, Dec 30, 2017 at 11:39:38AM -0500, Thomas Dickey wrote: On Sat, Dec 30, 2017 at 03:53:35PM +0100, Kamil Rytarowski wrote: How to setup correctly vt100 in a terminal? I've set exported TERM=vt100, called tset and stty and I keep observing artifacts. setting $TERM won't help with VMS :-) Now... you could use the xterm option to tell it (in effect) to tell the host not to send 8-bit controls: man xterm: -ti term_id Specify the name used by xterm to select the correct response to terminal ID queries. It also specifies the emulation level, used to determine the type of response to a DA control sequence. Valid values include vt52, vt100, vt101, vt102, vt220, and vt240 (the “vt” is optional). The default is “vt420”. The term_id argument specifies the terminal ID to use. (This is the same as the decTerminalID resource). That is, xterm -ti 100 or xterm -ti 102 and if the host is behaving properly, it'll give up on 8-bit controls. Of course, VT100's have no function keys (F1-F12), nor Home/End, PageUp/PageDown, but cursor-keys should work. Your experience here will depend on what the applications are using. This didn't help (starting "xterm -ti 100" on my NetBSD host and telneting to OpenVMS), however I have found the solution. I've set in OpenVMS the following option: SET TERMINAL/DEVICE_TYPE=vt100 py-terminator started to work correctly (and the same should happen with xterm). Thank you for your help! The reason for this is that the VMS host will not magically know what kind of terminal you have. You need to (as you noted) tell it what terminal you have. Sometimes system managers put in a SET TERMINAL/INQUIRE into the system wide login script. That will make VMS try to detect what terminal you have, and could potentially have solved the problem if xterm have the right settings as well, but I suspect there is no SET TERM/INQ in there to start with, and then it is not enough to just fiddle around in xterm. VMS needs to know, just as Unix programs needs to know what terminal you have. In VMS you do it they way you noted above, and in Unix, you do it by setting the TERM variable. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: vt100
On Sat, Dec 30, 2017 at 01:09:02PM -0500, Thomas Dickey wrote: > On Sat, Dec 30, 2017 at 06:38:16PM +0100, Kamil Rytarowski wrote: > > On 30.12.2017 17:41, Thomas Dickey wrote: > > > On Sat, Dec 30, 2017 at 11:39:38AM -0500, Thomas Dickey wrote: > > >> On Sat, Dec 30, 2017 at 03:53:35PM +0100, Kamil Rytarowski wrote: > > >>> How to setup correctly vt100 in a terminal? > > >>> > > >>> I've set exported TERM=vt100, called tset and stty and I keep observing > > >>> artifacts. setting $TERM won't help with VMS :-) Now... you could use the xterm option to tell it (in effect) to tell the host not to send 8-bit controls: man xterm: -ti term_id Specify the name used by xterm to select the correct response to terminal ID queries. It also specifies the emulation level, used to determine the type of response to a DA control sequence. Valid values include vt52, vt100, vt101, vt102, vt220, and vt240 (the “vt” is optional). The default is “vt420”. The term_id argument specifies the terminal ID to use. (This is the same as the decTerminalID resource). That is, xterm -ti 100 or xterm -ti 102 and if the host is behaving properly, it'll give up on 8-bit controls. Of course, VT100's have no function keys (F1-F12), nor Home/End, PageUp/PageDown, but cursor-keys should work. Your experience here will depend on what the applications are using. -- Thomas E. Dickey <dic...@invisible-island.net> https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature
Re: vt100
On 30.12.2017 19:25, Thomas Dickey wrote: > On Sat, Dec 30, 2017 at 01:09:02PM -0500, Thomas Dickey wrote: >> On Sat, Dec 30, 2017 at 06:38:16PM +0100, Kamil Rytarowski wrote: >>> On 30.12.2017 17:41, Thomas Dickey wrote: >>>> On Sat, Dec 30, 2017 at 11:39:38AM -0500, Thomas Dickey wrote: >>>>> On Sat, Dec 30, 2017 at 03:53:35PM +0100, Kamil Rytarowski wrote: >>>>>> How to setup correctly vt100 in a terminal? >>>>>> >>>>>> I've set exported TERM=vt100, called tset and stty and I keep observing >>>>>> artifacts. > > setting $TERM won't help with VMS :-) > > Now... you could use the xterm option to tell it (in effect) to tell > the host not to send 8-bit controls: > > man xterm: > >-ti term_id >Specify the name used by xterm to select the correct response >to terminal ID queries. It also specifies the emulation level, >used to determine the type of response to a DA control >sequence. Valid values include vt52, vt100, vt101, vt102, >vt220, and vt240 (the “vt” is optional). The default is >“vt420”. The term_id argument specifies the terminal ID to >use. (This is the same as the decTerminalID resource). > > That is, > > xterm -ti 100 > > or > > xterm -ti 102 > > and if the host is behaving properly, it'll give up on 8-bit controls. > > Of course, VT100's have no function keys (F1-F12), nor Home/End, > PageUp/PageDown, but cursor-keys should work. Your experience here > will depend on what the applications are using. > This didn't help (starting "xterm -ti 100" on my NetBSD host and telneting to OpenVMS), however I have found the solution. I've set in OpenVMS the following option: SET TERMINAL/DEVICE_TYPE=vt100 py-terminator started to work correctly (and the same should happen with xterm). Thank you for your help! signature.asc Description: OpenPGP digital signature
Re: vt100
On 30.12.2017 23:26, Johnny Billquist wrote: > On 2017-12-30 15:53, Kamil Rytarowski wrote: >> How to setup correctly vt100 in a terminal? > > A real vt100, or some emulator running under some windows system? There > is a huge difference... > >> I've set exported TERM=vt100, called tset and stty and I keep observing >> artifacts. > > What kind of artifacts? > Already fixed. The terminals were dizzy becase of LC_ALL. > I've tested lots of different emulators, and so far only xterm and DEC's > powerterm have worked fully correct. With xterm, you obviously need to > configure it to actually work like a vt100, and not some other funny thing. > > putty works fairly well, and I have only one known issue with that one. > I see, good to know! xterm and py-terminator started to behave sanely when tuned properly. signature.asc Description: OpenPGP digital signature
Re: vt100
On 30.12.2017 20:03, Thomas Dickey wrote: > This would be an improvement for your configuration: > > LC_ALL=C xterm -ti 102 This works! signature.asc Description: OpenPGP digital signature
Re: vt100
On 2017-12-30 21:56, John Nemeth wrote: On Dec 30, 7:56pm, Kamil Rytarowski wrote: } } } On 30.12.2017 19:39, Thomas Dickey wrote: } > - Original Message - } > | From: "Valery Ushakov" <u...@stderr.spb.ru> } > | To: netbsd-users@netbsd.org } > | Sent: Saturday, December 30, 2017 1:28:53 PM } > | Subject: Re: vt100 } > | } > | Kamil Rytarowski <n...@gmx.com> wrote: } > ... } > | } > | > I've uploaded screen shot of xterm and script(1) recording. } > | > } > | > http://netbsd.org/~kamil/vt100/ } > | } > | The typescript looks strange. Are you sure there was not accidental } > | conversion(s) to/from utf-8 somewhere along the path? } > } > That might be part of it, but the 233's are pretty clear. } > The host is responding with C1 controls, and that seems to be the main issue. } > Either make it work properly (I'd do that...) or back off and just be a VT100/VT102. } } I use the default options and I assume that something is wrong on the } NetBSD side. Why would you automatically assume that? That's a pessimatic viewpoint towards NetBSD. :-) } My only host change in my env(1)/NetBSD-host that might affect something is: } } LC_ALL=pl_PL.UTF-8 Given what Thomas Dickey said about the 8-bit controls earlier it sounds like you're failing to tell the OpenVMS side what type of terminal you have (i.e. it thinks that you have a VT220 or newer model when you only have a VT100). If this is the case, then it is user error on your part and not NetBSD's fault at all. In general, I agree. If I got everything right in this thread, the OP is trying to use xterm and other programs. And it fails both in some output (fail to parse some escape sequences) and input (fails with delete). There are several issues and problems with the whole thing. First of all, as others have mentioned, TERM is not for telling xterm how to work, but telling other programs what kind of terminal (in this case xterm) you are using, so that the program can send the correct sequence of characters to clear the screen (for example). The second problem is that the OP seems to have logged into a VMS system, and either explicitly told the system to use 8 bit control, or told the VMS system that he has a VT200 or newer. Both alternatives in the end makes VMS use 8 bit control characters. Meaning a sequence like CSI is not made up from ESC + "[", but instead 0233 (octal), which is the equivalent 8-bit control character for CSI. Now, getting UTF-8 anywhere near this is just going to cause total destruction. In general, if you want to talk to older systems, the first thing you need to kill is anything related to UTF-8 And then you still need to make sure that your terminal type that you use is correctly reflected in the terminal settings of the VMS system in this case (or the TERM variable, if you are on Unix). Finally, the delete problem, which is caused by people and programs today commonly using the BACKSPACE character for deleting, while older systems (especially non-Unix) using the DEL character for deleting. xterm can be made to use either, and you can even change by accessing a manu (CTRL+left mouse). Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: vt100
On 2017-12-30 15:53, Kamil Rytarowski wrote: How to setup correctly vt100 in a terminal? A real vt100, or some emulator running under some windows system? There is a huge difference... I've set exported TERM=vt100, called tset and stty and I keep observing artifacts. What kind of artifacts? I was trying to run http://invisible-island.net/vttest/ and it does not work well. Define "not work well" and exactly what you are doing. I've tested py-terminator and xterm with the same results. I'm working around the problems with vt100 with putty right now and this program works well. I've tested lots of different emulators, and so far only xterm and DEC's powerterm have worked fully correct. With xterm, you obviously need to configure it to actually work like a vt100, and not some other funny thing. putty works fairly well, and I have only one known issue with that one. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: vt100
On Dec 30, 7:56pm, Kamil Rytarowski wrote: } } This is an OpenPGP/MIME signed message (RFC 4880 and 3156) } --H7Bb8IIqJs63aHLgG8Qqh3EFAtEPqmouj } Content-Type: multipart/mixed; boundary="85Smcsqd4lp0oGdh86kR7TUq2Q6dvAdU4"; } protected-headers="v1" } From: Kamil Rytarowski <n...@gmx.com> } To: Thomas Dickey <dic...@his.com>, Valery Ushakov <u...@stderr.spb.ru> } Cc: netbsd-users@netbsd.org } Message-ID: <58d4e939-479d-3c35-2f83-223743267...@gmx.com> } Subject: Re: vt100 } References: <1874747553.1486653.1514659173675.javamail.r...@his.com> } In-Reply-To: <1874747553.1486653.1514659173675.javamail.r...@his.com> } } On 30.12.2017 19:39, Thomas Dickey wrote: } > - Original Message - } > | From: "Valery Ushakov" <u...@stderr.spb.ru> } > | To: netbsd-users@netbsd.org } > | Sent: Saturday, December 30, 2017 1:28:53 PM } > | Subject: Re: vt100 } > | } > | Kamil Rytarowski <n...@gmx.com> wrote: } > ... } > | } > | > I've uploaded screen shot of xterm and script(1) recording. } > | > } > | > http://netbsd.org/~kamil/vt100/ } > | } > | The typescript looks strange. Are you sure there was not accidental } > | conversion(s) to/from utf-8 somewhere along the path? } > } > That might be part of it, but the 233's are pretty clear. } > The host is responding with C1 controls, and that seems to be the main issue. } > Either make it work properly (I'd do that...) or back off and just be a VT100/VT102. } } I use the default options and I assume that something is wrong on the } NetBSD side. Why would you automatically assume that? That's a pessimatic viewpoint towards NetBSD. } My only host change in my env(1)/NetBSD-host that might affect something is: } } LC_ALL=pl_PL.UTF-8 Given what Thomas Dickey said about the 8-bit controls earlier it sounds like you're failing to tell the OpenVMS side what type of terminal you have (i.e. it thinks that you have a VT220 or newer model when you only have a VT100). If this is the case, then it is user error on your part and not NetBSD's fault at all. }-- End of excerpt from Kamil Rytarowski
Re: vt100
- Original Message - | From: "Kamil Rytarowski" <n...@gmx.com> | To: "Thomas Dickey" <dic...@his.com>, "Valery Ushakov" <u...@stderr.spb.ru> | Cc: netbsd-users@netbsd.org | Sent: Saturday, December 30, 2017 1:56:29 PM | Subject: Re: vt100 | | On 30.12.2017 19:39, Thomas Dickey wrote: | > - Original Message - | > | From: "Valery Ushakov" <u...@stderr.spb.ru> | > | To: netbsd-users@netbsd.org | > | Sent: Saturday, December 30, 2017 1:28:53 PM | > | Subject: Re: vt100 | > | | > | Kamil Rytarowski <n...@gmx.com> wrote: | > ... | > | | > | > I've uploaded screen shot of xterm and script(1) recording. | > | > | > | > http://netbsd.org/~kamil/vt100/ | > | | > | The typescript looks strange. Are you sure there was not | > | accidental | > | conversion(s) to/from utf-8 somewhere along the path? | > | > That might be part of it, but the 233's are pretty clear. | > The host is responding with C1 controls, and that seems to be the | > main issue. | > Either make it work properly (I'd do that...) or back off and just | > be a VT100/VT102. | > | | I use the default options and I assume that something is wrong on the | NetBSD side. | | My only host change in my env(1)/NetBSD-host that might affect | something is: | | LC_ALL=pl_PL.UTF-8 That would influence xterm, making it use UTF-8 for display. Since the C1 controls can be confused for UTF-8, there may be an additional problem with that (though xterm does recognize C1 controls mixed with UTF-8...). This would be an improvement for your configuration: LC_ALL=C xterm -ti 102 -- Thomas E. Dickey <dic...@invisible-island.net> http://invisible-island.net ftp://ftp.invisible-island.net
Re: vt100
On 30.12.2017 19:39, Thomas Dickey wrote: > - Original Message - > | From: "Valery Ushakov" <u...@stderr.spb.ru> > | To: netbsd-users@netbsd.org > | Sent: Saturday, December 30, 2017 1:28:53 PM > | Subject: Re: vt100 > | > | Kamil Rytarowski <n...@gmx.com> wrote: > ... > | > | > I've uploaded screen shot of xterm and script(1) recording. > | > > | > http://netbsd.org/~kamil/vt100/ > | > | The typescript looks strange. Are you sure there was not accidental > | conversion(s) to/from utf-8 somewhere along the path? > > That might be part of it, but the 233's are pretty clear. > The host is responding with C1 controls, and that seems to be the main issue. > Either make it work properly (I'd do that...) or back off and just be a > VT100/VT102. > I use the default options and I assume that something is wrong on the NetBSD side. My only host change in my env(1)/NetBSD-host that might affect something is: LC_ALL=pl_PL.UTF-8 signature.asc Description: OpenPGP digital signature
Re: vt100
- Original Message - | From: "Valery Ushakov" <u...@stderr.spb.ru> | To: netbsd-users@netbsd.org | Sent: Saturday, December 30, 2017 1:28:53 PM | Subject: Re: vt100 | | Kamil Rytarowski <n...@gmx.com> wrote: ... | | > I've uploaded screen shot of xterm and script(1) recording. | > | > http://netbsd.org/~kamil/vt100/ | | The typescript looks strange. Are you sure there was not accidental | conversion(s) to/from utf-8 somewhere along the path? That might be part of it, but the 233's are pretty clear. The host is responding with C1 controls, and that seems to be the main issue. Either make it work properly (I'd do that...) or back off and just be a VT100/VT102. -- Thomas E. Dickey <dic...@invisible-island.net> http://invisible-island.net ftp://ftp.invisible-island.net
Re: vt100
Kamil Rytarowski <n...@gmx.com> wrote: > How to setup correctly vt100 in a terminal? > > I've set exported TERM=vt100, called tset and stty and I keep > observing artifacts. Heh. This is not how terminals work. Forget about terminal emulators for a momemnt. Back in the day people used real CRT terminals and each terminal model understood/spoke its own language. On the host side you would use TERM variable to tell your *programs* which language they need to speak. If you were using, say, Wyse terminals, you couldn't magically make them into a vt100 by setting TERM on the host. OTOH some (many?) terminals supported several languages and you could use your terminal's setup menu to tell it to speak DEC VT. > I've uploaded screen shot of xterm and script(1) recording. > > http://netbsd.org/~kamil/vt100/ The typescript looks strange. Are you sure there was not accidental conversion(s) to/from utf-8 somewhere along the path? -uwe
Re: vt100
On Sat, 30 Dec 2017, the wise Kamil Rytarowski wrote: I'm attempting to login to OpenVMS and it's breaking the screen with vt100 sequences. Command line mostly works, but editors and other programs aren't usable. I'm having the same problem. Login in with ssh into my OpenVMS machine with xterm causes problems (no backspace or delete). But when using qterminal, no problems. So it seems to be a specific xterm thing. Regards, Marco -- Walk softly and carry a big stick. -- Theodore Roosevelt
Re: vt100
On Sat, Dec 30, 2017 at 06:38:16PM +0100, Kamil Rytarowski wrote: > On 30.12.2017 17:41, Thomas Dickey wrote: > > On Sat, Dec 30, 2017 at 11:39:38AM -0500, Thomas Dickey wrote: > >> On Sat, Dec 30, 2017 at 03:53:35PM +0100, Kamil Rytarowski wrote: > >>> How to setup correctly vt100 in a terminal? > >>> > >>> I've set exported TERM=vt100, called tset and stty and I keep observing > >>> artifacts. > >>> > >>> I was trying to run http://invisible-island.net/vttest/ and it does not > >>> work well. > >>> > >>> I've tested py-terminator and xterm with the same results. > >>> > >>> I'm working around the problems with vt100 with putty right now and this > >>> program works well. > >> > >> hmm - looking at this and followup, there's no information regarding > >> what exactly is going wrong. > >> > >> That (plus the actual version number for vttest and xterm would help). > >> For py-terminator - no help there. > > > > For "artifacts", it helps to know that you can capture all of the characters > > sent by a host to the terminal using the "script" program. If you had > > sent a bug report, I'd ask for that information, to point to the likely > > problem. > > > > I've uploaded screen shot of xterm and script(1) recording. > > http://netbsd.org/~kamil/vt100/ The typescript shows that the remote host is using 8-bit controls. None of the VTE-based terminals will work with that, likely never will. xterm should do this -- you can see that using the menu at the bottom of vttest: Menu 12: Modify test-parameters but the host likely is not initializing the terminal to do this - it could be assuming you did that already. Ignoring the padding nulls, "unmap" https://invisible-island.net/misc_tools/index.html#item:unmap shows this: \n4\372\313GZ<1^NoConnected to localhost.\r \nEscape character is '\^]'.\r \n@^A\314GZ\260\376^Do \n\r \nConnected to the MicroVAX 3900 simulator CON-TELNET device\r \n \n^A^G\314GZl\270i\r^A^G\314GZ7\273o\r^E^G\314GZ\264\275^Co \n\r$ ^A\t\314GZ\330\360^Aid^A\t\314GZm\364^Aod^A\t\314GZ\277\330^Eii^A\t\314GZ\267\354^Eoi^A \n\314GZ&^\ir^A \n\314GZh^\or^A \n\314GZD^]^Ei\r^A \n\314GZU#^Eo\r^D \n\314GZ\2520\bo \n\r \nDirectory SYS$SYSROOT:[SYSMGR]\r \n\r \nACCOUNTNG.DAT;1 CLUE$HISTORY.DATA;1 CLUE$LAST_MYVAX.LIS;1\r \nLAN$ACP.LOG;5 LAN$ACP.LOG;4 LAN$ACP.LOG;3 LAN$ACP.LOG;2 \r \nLAN$ACP.LOG;1 OPERATOR.LOG;5 OPERATOR.LOG;4 OPERATOR.LOG;3 \r \nOPERATOR.LOG;2 OPERATOR.LOG;1 VMSIMAGES.DAT;1 \r \n\r \nTotal of 14 files.\r \n\r \nDirectory SYS$COMMON:[SYSMGR]\r \n\r \nAGEN$NEW_NODE_DEFAULTS.DAT;1AGEN$NEW_NODE_DEFAULTS.TEMPLATE;1\r \nAGEN$NEW_SATELLITE_DEFAULTS.DAT;1 AGEN$NEW_SATELLITE_DEFAULTS.TEMPLATE;1\r \nAGENPARAMS.EXE;1ALFMAINT.COM;1 AMDS$DRIVER_ACCESS.DAT;1\r \nAMDS$DRIVER_ACCESS.TEMPLATE;1 AMDS$LOGICALS.COM;1 AMDS$LOGICALS.TEMPLATE;1\r \nAMDS$SYSTARTUP.TEMPLATE;1 CLUSTER_CONFIG.COM;1\r \nCLUSTER_CONFIG_LAN.COM;1CTF$STARTUP.COM;1 DBLSTRTUP.COM;1 \r \nDCE$RPC_SHUTDOWN.COM;1 DCE$RPC_STARTUP.COM;1\r \nDECNET_DNS_REGISTER.COM;1 DECNET_DNS_TOWERS.COM;1\r \nDECNET_LOC_REGISTER.COM;1 DECNET_REGISTER_DECDNS.CO^D \n\314GZ\3120\boM;1\r \nDECW$DEVICE.COM;1 DECW$DEVICE_GE.COM;1 DECW$DEVICE_GF.COM;1\r \nDECW$DEVICE_GG.COM;1DECW$PRIVATE_SERVER_SETUP.TEMPLATE;1\r \nDECW$RGB.DAT;1 DECW$STARTSERVER.COM;1 DECW$STARTXTERMINAL.COM;1\r \nDNS$CHANGE_DEF_FILE.COM;1 DNS$CLERK_CLUSTER.NCL;1\r \nDNS$CLIENT_STARTUP.COM;1DNS$CLIENT_STOP.COM;1\r \nDNS$CONFIGURE.COM;1 DTSS$CONFIG.COM;1 DTSS$CONFIG_TEMPLATE.DAT;1\r \nEDTINI.TEMPLATE;1 ICC$ADD_REGISTRY_TABLE.COM;1 ICC$CREATE_SECURITY_OBJECT.COM;1\r \nLAT$SYSTARTUP.COM;1 LAT$SYSTARTUP.TEMPLATE;1 LIB$DT_STARTUP.COM;1\r \nLOGIN.COM;1 LOGIN.TEMPLATE;1LPA11STRT.COM;1 LTLOAD.COM;1 \r \nMAKEROOT.COM;1 NET$AUTOGEN.COM;1 NET$CONFIGURE.COM;1 NET$DNS_CLERK_STARTUP.NCL;1\r \nNET$DNS_CLERK_STOP.NCL;1NET$DTSS_CLERK_STARTUP.NCL;1\r \nNET$EVENT_LOCAL.TEMPLATE;1 NET$LOGICALS.TEMPLATE;1\r \nNET$SHUTDOWN.COM;1 NETTRACE_INSTALL.COM;1 NETTRACE_SECURITY.COM;1\r \nRTTLOAD.CO^Q^C \n\314GZ\3400\boM;1 SECURITY.AUDIT$JOURNAL;1 SMISERVER.COM;1\r \nSYCONFIG.COM;1 SYCONFIG.TEMPLATE;1 SYLOGICALS.COM;1 SYLOGICALS.TEMPLATE;1\r \nSYLOGIN.COM;1 SYLOGIN.TEMPLATE;1 SYPAGSWPFILES.COM;1 SYPAGS
Re: vt100
On Sat, Dec 30, 2017 at 11:39:38AM -0500, Thomas Dickey wrote: > On Sat, Dec 30, 2017 at 03:53:35PM +0100, Kamil Rytarowski wrote: > > How to setup correctly vt100 in a terminal? > > > > I've set exported TERM=vt100, called tset and stty and I keep observing > > artifacts. > > > > I was trying to run http://invisible-island.net/vttest/ and it does not > > work well. > > > > I've tested py-terminator and xterm with the same results. > > > > I'm working around the problems with vt100 with putty right now and this > > program works well. > > hmm - looking at this and followup, there's no information regarding > what exactly is going wrong. > > That (plus the actual version number for vttest and xterm would help). > For py-terminator - no help there. For "artifacts", it helps to know that you can capture all of the characters sent by a host to the terminal using the "script" program. If you had sent a bug report, I'd ask for that information, to point to the likely problem. -- Thomas E. Dickey <dic...@invisible-island.net> https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature
Re: vt100
On Sat, Dec 30, 2017 at 03:53:35PM +0100, Kamil Rytarowski wrote: > How to setup correctly vt100 in a terminal? > > I've set exported TERM=vt100, called tset and stty and I keep observing > artifacts. > > I was trying to run http://invisible-island.net/vttest/ and it does not > work well. > > I've tested py-terminator and xterm with the same results. > > I'm working around the problems with vt100 with putty right now and this > program works well. hmm - looking at this and followup, there's no information regarding what exactly is going wrong. That (plus the actual version number for vttest and xterm would help). For py-terminator - no help there. -- Thomas E. Dickey <dic...@invisible-island.net> https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature
Re: vt100
On 30.12.2017 17:41, Thomas Dickey wrote: > On Sat, Dec 30, 2017 at 11:39:38AM -0500, Thomas Dickey wrote: >> On Sat, Dec 30, 2017 at 03:53:35PM +0100, Kamil Rytarowski wrote: >>> How to setup correctly vt100 in a terminal? >>> >>> I've set exported TERM=vt100, called tset and stty and I keep observing >>> artifacts. >>> >>> I was trying to run http://invisible-island.net/vttest/ and it does not >>> work well. >>> >>> I've tested py-terminator and xterm with the same results. >>> >>> I'm working around the problems with vt100 with putty right now and this >>> program works well. >> >> hmm - looking at this and followup, there's no information regarding >> what exactly is going wrong. >> >> That (plus the actual version number for vttest and xterm would help). >> For py-terminator - no help there. > > For "artifacts", it helps to know that you can capture all of the characters > sent by a host to the terminal using the "script" program. If you had > sent a bug report, I'd ask for that information, to point to the likely > problem. > I've uploaded screen shot of xterm and script(1) recording. http://netbsd.org/~kamil/vt100/ py-terminator works correctly with the delete key, but otherwise they present the same result on the screen. signature.asc Description: OpenPGP digital signature
Re: vt100
n...@gmx.com (Kamil Rytarowski) writes: >> So if you want a true VT100 emulation, you will either have to tell >> xterm to be faithful to vt100 (TERM=3Dvt100 tells programs to generate >> vt100 codes), or find some other terminal emulator which is switchable.= >How to do it? I've tried to export TERM=3Dvt100 without success. The xterm emulation is (more or less) fixed. Setting TERM doesn't control xterm but tells other programs what the terminal expects. Since TERM=xterm and TERM=vt100 is almost the same, either works for most programs. Other terminal emulators may offer a more precise or complete VT100 emulation. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: vt100
Kamil Rytarowski <n...@gmx.com> writes: >> xterm tries to implement the ansi sequences, more or less. I am not >> aware of a way to make it be exactly vt100. >> > > Are the ANSI sequences conflicting with DEC VT100? No. The common subset betweeen what's implemented by VT100 and the ANSI spec is basically the useful part. There are then some things only in VT100 and ANSI. It may be that VMS is the only thing to use VT100 non-ansi sequences. >> So if you want a true VT100 emulation, you will either have to tell >> xterm to be faithful to vt100 (TERM=vt100 tells programs to generate >> vt100 codes), or find some other terminal emulator which is switchable. >> > > How to do it? I've tried to export TERM=vt100 without success. I am not sure that it's doable. But, I really would expect xterm to do the right thing for all actual VT100 sequences, plus to respond to sequences from later terminals. >> What are you really trying to accomplish? Are you looking to see if >> our xterm has bugs? > > I'm attempting to login to OpenVMS and it's breaking the screen with > vt100 sequences. Command line mostly works, but editors and other > programs aren't usable. Ah, software retrocomputing! > I've only managed to login to the machine and get sane output with > putty, but it's not a convenient terminal of mine - I want to use > py-terminator. I guess you can log the sequences and figure out what's going wrong. Not that "debug it" is actually a helpful answer :-) I would ask on OpenVMS lists/forums. People use xterm all the time without issues, and it seems like a lot of effort went into it doing the right thing. So I suspect OpenVMS is doing something that is unusual. Still, I'd be surprised if there were any documented VT100 escape sequences that xterm didn't do right. But it is interesting if vttest and our xterm don't play well together. signature.asc Description: PGP signature
Re: vt100
On 30.12.2017 16:35, Greg Troxel wrote: > > Kamil Rytarowski <n...@gmx.com> writes: > >> How to setup correctly vt100 in a terminal? >> >> I've set exported TERM=vt100, called tset and stty and I keep observing >> artifacts. >> >> I was trying to run http://invisible-island.net/vttest/ and it does not >> work well. >> >> I've tested py-terminator and xterm with the same results. >> >> I'm working around the problems with vt100 with putty right now and this >> program works well. > > The VT100 had a specific series of escape sequences. Memory is fuzzy on > timing/ordering, but we ended up with an ANSI standard for terminal > escape sequences that is mostly the same as VT100. There are some DEC > things in vt100 but not ANSI, and later ANSI grew color support (VT100, > VT220, VT320 are monochrome) > > xterm tries to implement the ansi sequences, more or less. I am not > aware of a way to make it be exactly vt100. > Are the ANSI sequences conflicting with DEC VT100? > So if you want a true VT100 emulation, you will either have to tell > xterm to be faithful to vt100 (TERM=vt100 tells programs to generate > vt100 codes), or find some other terminal emulator which is switchable. > How to do it? I've tried to export TERM=vt100 without success. > What are you really trying to accomplish? Are you looking to see if > our xterm has bugs? > I'm attempting to login to OpenVMS and it's breaking the screen with vt100 sequences. Command line mostly works, but editors and other programs aren't usable. I've only managed to login to the machine and get sane output with putty, but it's not a convenient terminal of mine - I want to use py-terminator. signature.asc Description: OpenPGP digital signature
Re: vt100
In article <8c23b3c8-4fba-34b5-695d-66724b71f...@gmx.com>, Kamil Rytarowski <n...@gmx.com> wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >How to setup correctly vt100 in a terminal? > >I've set exported TERM=vt100, called tset and stty and I keep observing >artifacts. > >I was trying to run http://invisible-island.net/vttest/ and it does not >work well. > >I've tested py-terminator and xterm with the same results. > >I'm working around the problems with vt100 with putty right now and this >program works well. Perhaps the program is testing escape sequences that are only supported by some emulations like double width characters etc. christos
Re: vt100
Kamil Rytarowski <n...@gmx.com> writes: > How to setup correctly vt100 in a terminal? > > I've set exported TERM=vt100, called tset and stty and I keep observing > artifacts. > > I was trying to run http://invisible-island.net/vttest/ and it does not > work well. > > I've tested py-terminator and xterm with the same results. > > I'm working around the problems with vt100 with putty right now and this > program works well. The VT100 had a specific series of escape sequences. Memory is fuzzy on timing/ordering, but we ended up with an ANSI standard for terminal escape sequences that is mostly the same as VT100. There are some DEC things in vt100 but not ANSI, and later ANSI grew color support (VT100, VT220, VT320 are monochrome) xterm tries to implement the ansi sequences, more or less. I am not aware of a way to make it be exactly vt100. So if you want a true VT100 emulation, you will either have to tell xterm to be faithful to vt100 (TERM=vt100 tells programs to generate vt100 codes), or find some other terminal emulator which is switchable. What are you really trying to accomplish? Are you looking to see if our xterm has bugs? signature.asc Description: PGP signature
vt100
How to setup correctly vt100 in a terminal? I've set exported TERM=vt100, called tset and stty and I keep observing artifacts. I was trying to run http://invisible-island.net/vttest/ and it does not work well. I've tested py-terminator and xterm with the same results. I'm working around the problems with vt100 with putty right now and this program works well. signature.asc Description: OpenPGP digital signature
