Purpose: Discuss the use of Tcl in an interactive manner. Pointers to relevant pages and tools are also welcome here.
Tcl can be used in several ways. This page talks about the user of Tcl in an interactive manner. Other pages [fill in some names here] discuss the use of Tcl with files, command lines, in web applications, etc.
So why would anyone ever use Tcl interactively? Tcl is an interpreter, and as such, interacting with it allows one to experiment with the language, as well as allows one to solve some kinds of simple problems.
So, how do you use Tcl in this way?
First, you have to find a Tcl interpreter. These can come named in various ways. A few of the more common ones are:
Next, you execute the Tcl interpreter. If you do this from a command line text type window, you will see a prompt of some kind - what kind depends on the interpreter. (Tcl typically shows a % sign). To assure yourself that you are in Tcl, type:
info patchlevel
[someone feel free to replace this command with something else uniquely Tclish]
and you should get the version of the Tcl being used. Especially when used interactively, errors in Tcl are not catastrophes to be feared, but like little friends that help in learning. Here's an example session (making use of various info subcommands): after the % is my input, in the next line starts the output from that command.
% info
wrong # args: should be "info option ?arg arg ...?"
% info option
bad option "option": must be args, body, cmdcount, commands, complete, default,
exists, functions, globals, hostname, level, library, loaded, locals, nameofexec
utable, patchlevel, procs, script, sharedlibextension, tclversion, or vars
% info patchlevel
8.4.1
% info nameof
D:/usr/local/bin/tclsh.exe
% info vars
tcl_rcFileName tcl_version argv argv0 tcl_interactive auto_oldpath auto_path err
orCode errorInfo auto_index env tcl_patchLevel argc tcl_libPath tcl_platform tcl
_library
% set tcl_platform
can't read "tcl_platform": variable is array
% array set tcl_platform
wrong # args: should be "array set arrayName list"
% array get tcl_platform
osVersion 5.0 byteOrder littleEndian machine intel platform windows os {Windows
NT} user suchrich wordSize 4
% pwd
D:/home/suchrich/bld/smart/bld/zvutil/build
% expr 17+4
21
%If the interpreter initializes Tk, you will also see a small blank window, which represents a Tk toplevel widget known as ".". It looks strange, as it is empty, you can't initially type in it, etc. However, the window represents the place where your subsequent declarations of buttons, etc. will appear once you issue the appropriate manager commands.
[Someone please fill in what someone from a GUI environment (like Windows, MacOSX, or X) needs to do here so that double clicking on a tclsh or wish, etc. does the right thing.] [Define right thing]
The Tcl command
console show
on some platforms - Windows at least (perhaps MacOS as well) displays a Tk window into which one can type commands and see the results.
ET: I've been thinking about a TIP to ask this to be implemented on all platforms. There was once some code I had which actually would make this work on unix but since I mostly develop on windows, I forgot what happened to it. It did come with a caveat that their trick would likely break in a future release. Another possibility would be to have Tkcon always available. The current tclkit I have does not seem to have it built in.
LV There is at least one, perhaps more, wiki pages with code to take care of this.
In addition to this, I'd like to see a built in help command. Or possibly a -help option for all commands (perhaps as an error exception - I'm only guessing that this might easy to implement w/o changing individual commands). Every interactive debugger, like gdb, has a minimum help facility built in.
And one trick I was shown was how to display a .widget configure output in a more readable way:
join [.widget configure] \n
And I would also like to see a number of built in small utilities like corp.
I have a few of my own, but since they're not readily available without some effort (sftp etc.), I didn't want to get to used to using them nor show them to beginners who might wonder why they did not work for them. I often demonstrate "out of the box" TCL/TK wish sessions interactively. Here's the output, though, of one of my global variable listers:
% lg a* --- argc = /0/ --- argv = // --- argv0 = /F:/Tcl/bin/wish84.exe/ --- auto_execs = config --- auto_index = ::auto_mkindex_parser::cleanup ::auto_mkindex_parse --- auto_oldpath = /F:/Tcl/lib/tcl8.4 F:/Tcl/lib F:/Tcl/lib/tcllib1.5 --- auto_path = /F:/Tcl/lib/tcl8.4 F:/Tcl/lib F:/Tcl/lib/tcllib1.5
I'd post the code, except that it's not very smart about things and can easily blow up. It was a very early attempt. While global is sometimes frowned upon, I use it for all my widget variables in small programs and especially when demonstrating TK programming.
[To be added - more examples]
See also TkCON - a great interface for interacting with Tcl. Provides the ability to use the arrow keys to go back in the entered history and edit and then reexecute lines, interact with interpreters, etc.
18mar03 jcw - I've been experimenting with another way to make the edit/run cycle very direct. It could be done with periodic polling, but on Linux, there's also a neat utility called "dnotify" which will run a specified command whenever a change is detected in a certain directory. Dnotify actually hooks into the kernel to respond instantly, so what you can do is issue the following command:
dnotify -r . -e ./try.tcl
In plain english: whenever a file in the current dir is renamed, run the "try.tcl" script. With this running in one window, you can go to any of the files, edit and then simply save (which renames, at least in "vi"). Each save will refresh the output. Does wonders, as long as the pieces being developed are small and self-contained. TV mar 31 03 interesting thinking, like interaction processing, though I guess it makes sense to make some standard way to deal with interaction, especially between all kinds of applications. I guess the save with vi could get into trouble with the autosave?
ET: I have some programs that it is annoying to have to restart when I make small changes to the proc I'm working on. The editor I use lets me click anywhere inside a proc, click a toolbar macro which finds and selects the entire proc and then copy's to the clipboard. At that point, one more click in the console window with a paste and the proc is replaced. There is usually some gui button as part of my program which invokes the procedure for testing the new version. This simple trick lets me add puts's (or any other dumper I might have) anywhere I want w/o reloading the entire program, and all widgets and global variables are correctly setup. I don't even bother to save the changes from the editor until I'm nearly finished, and have removed or commented out any debug code.
AET: 01may06 Tkcon does this a little better, though the editor is very basic. This is the procedure I use (Windows). Start my editor (Crimson is good). Open my program in the editor. Start Tkcon. CNTRL-S to select the program in the editor, copy and paste the contents into Tkcon. Then you can run any proc from the command line. Double-click on the proc name, and a Tkcon editor window pops up with just the proc loaded. Make your adjustments, and alt-s-s will save the proc to the running console. When you are satisfied, copy & paste the revised proc into your editor & save. Double click on a variable name, and a window pops up with the current value, which you can change. It is well worth the effort of reading the Tkcon documentation. There's a lot of hidden value there.
escargo 31 Mar 2003 - It's hard to believe that nobody had mentioned Tcl Tutor, which provides interactive lessons for learning Tcl.
LV that's a good thought. When I created this page, I was trying to address the audience I've seen growing in the past few months of people who thought that Tcl or Tk was broken because when they executed the interpreter, all they got was a prompt, or perhaps a prompt and a weird empty window, no keyboard history scrolling buffer, etc. I've seen this reaction particularly from Windows and MacOS users, who are more used to interpreters having some sort of attractive graphical interface - whereas Tcl is distributed in something more akin to applications written in the 1960s depending on text terminals.
See also Talk to me, Tcl
See XOTclIDE that is interactive IDE for Tcl. There are no edit-save-run cycles because edited (confirmed) proc is evaluated immediately in interpreter and saved just in time into version control. IDE is just gui for interpreter and some version control.
lihtox 4 Jun 2012: I wrote a little script (Interactive procedure editor) that makes it easier to edit individual procedures in the interactive environment, without re-evaluating your entire script. Hope it's useful.