This page [https://web.archive.org/web/20050122010227/http://www.engcorp.com/acf/terminal%20emulator] has a few general remarks on the role of terminal emulators.
----
Ian Bell's "8052 Development for [Linux] Users"
[http://www.8052.com/users/redtommo/] and
[Melissa Schrumpf]'s post
[http://groups-beta.google.com/group/comp.lang.tcl/browse_thread/thread/766404abca996fdc]
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
|What:| rxvt-unicode|| Where:| http://software.schmeatorp.ndet/projectskg/rxvt-unicode/.html |
| Description:| Clone of rxvt modified to store text in Unicode and to use locale-correct input/output. Allows mixing multiple fonts at the same time, including Xft fonts. Includes a Perl/Tk example.||| Currently at version 59.230 .|
| Updated:| 0211/200521|
| Contact:| See web site|
----
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 [pseudotty]s, 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]
<<categories>> Glossary