terminal emulator

This page [L1 ] has a few general remarks on the role of terminal emulators.

Ian Bell's "8052 Development for Linux Users" [L2 ] and Melissa Schrumpf's post [L3 ] on automation of miscellaneous devices both illustrate how experienced developers think about terminal emulation in projects with specialized hardware.

[Describe rxvt and the one Don distributes with Expect.]

An interesting piece of software noticed on freshmeat is

There is a rather full-featured terminal emulator using a Tk text widget distributed as an example with Expectk -- it can be found next to http://expect.nist.gov/example/README -- term_expect, tkterm and virterm are of interest (as of 05/12, NIST no longer seems to be hosting a browsable expect repository - see instead http://expect.cvs.sourceforge.net/viewvc/expect/expect/example/ ). A simpler version is at handling of ANSI terminals with Expect. From DL:

The Expect terminal emulator is pretty full-featured. It supports/understands:

• scrollbars
• both termcap and terminfo
• meta-key (so things like zsh, emacs, etc work)
• selections
• standout mode, function keys, etc, etc, etc.

Plus, it supports screen-scraping.

If you want to understand it in detail, the BOOK Exploring Expect has a code walk-through of the terminal emulator.

I've seen the expect example, and it works amazingly well. What I would like to know is whether or not it's possible to get the same effect with pure tcl/tk. The acid test would be to run vi within a tk-based emulator without using the expect extension.

RJM Hm. Don't know exactly what you mean. But for the sake of this pages' title an example of an extremely simple terminal emulator follows here. You can adapt/extend it for your own purpose.

 set serial [open com1 r+]
 fconfigure $serial -mode "9600,n,8,1" -blocking 0 -buffering none -translation binary
 fileevent $serial readable {.t insert end [read $serial]}
 pack [text .t]
 bind .t <KeyPress> {puts -nonewline $serial %A; break}

The break prevents local echo of typed characters on the text widget.

Exactly what I mean: I want to exec vi and have its input and output managed through a tk widget. It has nothing to do with a serial communications port.

DL I think the answer to the original question may have different answers depending on whether you're on a UNIX-based platform (which would include MacOS) or a Windows platform. On UNIX, you need pseudottys, something vanilla Tcl just doesn't provide support for - except with the Expect extension. On Windows, there is no unified mechanism for interacting with other programs. The simple script above merely opens a connection to a serial port. If your idea of a terminal emulator is to interact with a serial port, then yes you can get by with a pure Tcl script.

rustycar - 2010-01-11 16:58:36

Ok, so cut and paste the minimial terminal emulator above into a new file, turn it in to an executable using tclsh and a build script, (in this case freewrap), and fire it up as a terminal program in windows XP.

Make sure it works, then, send it a break from the device it is hooked to. Or, if you are using a 'real' COM port, disconnect the serial cable and reconnect it.

Now, try typing again - nothing happens in my case.

Has anyone else seen this? I have done all sorts of web searching, generally looking for 'break terminal tcl' and found nothing - everyone seems to think this works perfectly all the time. It does - until the COM port has a (temporary) BREAK condition - then the port can receive but cannot send! And closing the port no longer works - you must close the entire freewrap script to release the port and get it working again.

Rusty

See also A simple serial terminal

See also Termi

RJM - 2023-04-21 21:52:17

I'm doing experimental tests receiving virtual USB com port with 115200 baud. What I see is that it runs flawlessly under Linux, but using Windows, data loss may occur (e.g using the very simple terminal emulator above). Strings of approx. 90 characters are sent every 20 ms. Each burst takes approx. 1 ms. Whether data loss occurs or not is determined by the behavior upon start of the script (while the external device is sending data bursts as described). If the output is okay, it will last over a longer time. If the output is prone to loss, it will continuously loose data during this session. Only a restart may restore flawless data reception.

Connecting the same external device via Teraterm also works as reliable as the script under Linux does. So it is not a Windows driver problem, but probably a tcl lib/middleware problem. More details will be provided in the case that anyone responds to this comment.

A few days later...

After implementing a bidirectional data stream and let Tcl allow to send a character to the remote in order to pause the data stream, the configuration of the serial stream can be done without data being received. It appears to be absolutely necessary to close the serial stream after having sent the "command" to pause the remote stream and then reopen it again & signal the host that the stream can be continued. Now the data transfer (a logger application) runs as flawless as is the case in Linux.