This FAQ file is intended to address some of the most commonly asked questions regarding the Tcl programming language. It is hoped that by addressing these here in this document, that the postings to comp.lang.tcl will be of a less repetitive and more informative nature. It is also hoped that via this and other available resources, more and more people will be able to utilize Tcl and Tcl based applications.
This FAQ is maintained by Joe Moss (jmoss@ichips.intel.com) and is posted monthly to comp.lang.tcl and news.answers and can also be obtained from the Tcl archive at ftp.neosoft.com/pub/tcl in the /pub/tcl/alcatel/docs directory or via the World Wide Web as http://www.psg.com/~joem/tcl/faq.html.
Note that this FAQ deals with Tcl, not with Tk. For Tk Toolkit Q&As see the FAQ posting by Jeffrey Hobbs (jhobbs@cs.uoregon.edu) which available from http://www.cs.uoregon.edu/research/tcl/faqs/tk/ as well from the Neosoft archive. However, there is some inevitable overlap. Some of the most commonly asked questions about usage of the Tk widgets are due to misunderstandings of how the Tcl interpreter works. These issues may still be addressed here. Also, some examples of Tcl usage may involve the use of the Tk widgets.
Questions and Answers about the use of non-Tk related extensions (such as Extended Tcl and Expect, but not TkX, expectk, BLT, etc.) are also appropriate here.
See the question below, entitled "Where can I get further info about Tcl" for pointers to other Tcl FAQs).
The source of this document is maintained in HTML. It is then run through a script (written in Tcl, of course) to automagically generate the Index of Questions, number the questions, generate the URL list, and add the From and Subject lines to the text version. The version available via the WWW will be updated whenever there are changes, while the ASCII text version will be generated and posted once a month.
NOTE: Posting has been suspended for the past many months. It should resume soon.
Last modified: Fri Aug 22 13:57:48 PDT 1997
glob cut off the first two characters of each filename?
The newsgroup comp.lang.tcl is for discussion of the Tcl language and packages based on it. There are several FAQ documents related to Tcl available from ftp.neosoft.com in the /pub/tcl/alcatel/docs directory that provide further information and pointers to yet more reading material, both on-line and in print. They can also be accessed via the World Wide Web: http://www.teraform.com/~lvirden/tcl-faq/
Three other good starting points, if you are surfing the Web for
information, are:
http://www.sco.com/Technology/tcl/Tcl.html
http://web.cs.ualberta.ca/~wade/HyperTcl/
http://sunscript.sun.com/
If you're just getting started doing some programming in Tcl, you might want to take a look at the frequently made mistakes page at: http://starbase.neosoft.com/~claird/comp.lang.tcl/fmm.html
Of course, the source distribution itself includes a great
deal of documentation.
The latest version is 8.0.
It can be obtained from:
ftp://ftp.sunlabs.com/pub/tcl/
Look in the Tcl distribution for the file called porting.notes. This will contain a collection of notes that various people have provided about porting Tcl to various machines and operating systems. There is also a file called README which should be read FIRST - before doing anything else with the code (this should always be one's first step with any package).
You should also check the on-line database of porting information.
There are also some questions and answers related to building the interpreter on various platforms at the end of this document.
Tcl was intended to be used along with C code. Because of this, there are several ways to combine the two. Here is a list of some of them (with man page references for further info):
The last two do not provide nearly the same level of integration as those near the top of the list, but they are necessary if you do not have access to the source code.
There is plenty of documentation available that explains this in further detail. See the TclCommandWriting man page, included with Extended Tcl or available via the WWW at http://psg.com/~joem/CmdWrite.html
See also part two of Larry's Tcl FAQ and the Tcl Bibliography for other references.
In addition to all the ways possible with standard Tcl, several extensions add others, notably via pseudo-ttys with expect, and via X event, file event, timer, and idle callback handlers with Tk.
Also check out Embedded Tk, available from ftp://ftp.vnet.net/pub/users/drh/ and SWIG, available from ftp://ftp.cs.utah.edu/pub/beazley/SWIG/
With recent versions of Tcl and extensions that have been updated to work with them, this is not a problem as the extensions can easily be dynamically loaded. This is especially true with Tcl 8.0 which includes a namespace facility to avoid possibly conflicts between extensions.
The rest of this section discusses the situation with older Tcl versions or extensions that are configured to be loaded dynamically.
The simple answer is to create a custom Tcl_AppInit function to call the Init procedures for each of the desired extensions. This can be done by copying the tclAppInit.c (tkAppInit.c for Tk apps) file from Tcl source distribution, modifying it, and then linking your Tcl_AppInit function with the Tcl library. For example, the standard Tcl_AppInit looks like this:
int
Tcl_AppInit(interp)
Tcl_Interp *interp; /* Interpreter for application. */
{
/* ... */
if (Tcl_Init(interp) == TCL_ERROR) {
return TCL_ERROR;
}
/* ... */
}
In order to add the foo extension, you would add a call
to the foo init function, like this:
int
Tcl_AppInit(interp)
Tcl_Interp *interp; /* Interpreter for application. */
{
/* ... */
if (Tcl_Init(interp) == TCL_ERROR) {
return TCL_ERROR;
}
if (Foo_Init(interp) == TCL_ERROR) {
return TCL_ERROR;
}
/* ... */
}
For more information, see the Tcl_AppInit man page and the tclAppInit.c file.
The more complete answer is that the simple answer doesn't always work. Many extensions require more extensive modifications and the way to combine them depends on the specific extensions involved.
If you wish to include Extended Tcl, you should start with the Tcl_AppInit function that comes with it. Also make sure when you link the program that you include the Extended Tcl library before the standard Tcl library, for example:
cc -o mytclsh mytclXAppInit.c -ltclx -ltcl ...
or for an interpreter including the Tk extensions:
cc -o mywish mytkXAppInit.c -ltkx -ltk -ltclx -ltcl ...
On the positive side, there are also several packages available that can aid in combining extensions, such as Tcl-my-fancy, or extensions that include configuration files for combining them with other popular extensions. For example, several extensions written by Sven Delmas allow you to specify options to configure to generate a Makefile that will build an interpreter containing the specified extensions. See part five of Larry Virden's FAQ for the location of these and other packages.
The "Plus" patches from Jan Nijtmans (nijtmans@nici.kun.nl) include a make target for building a standalone interpreter. See http://www.nici.kun.nl/tkpvm/pluspatch.html
Additionally, Earle Lowe (lowee@cpsc.ucalgary.ca) has replied that:
If you want to create a stand-alone program that will run anywhere regardless of the presence/absence of TCL/Tk, than you need to go through some more work.
Basically, this involves converting the TCL init files to C strings, and then rather than calling Tcl_Init() and Tk_Init(), you call Tcl_Eval() with the converted C strings as arguments.
I suggest getting the wish_compiler package by Alexei Rodriguez (alexei@cis.ufl.edu) from ftp://ftp.neosoft.com/pub/tcl/alcatel/code/wish_compiler.shar.gz
This package contains a tcl2c converter, and instructions as to its use.
With some Makefile magic, you can use TCL/Tk as intended (as an interpreted language using some version of wish) and when the code works, you can create a stand-alone compiled program.
Another option that is available is "Embedded Tk". You can get it from ftp://ftp.vnet.net/pub/users/drh/
There are several tricks you can use, but the most common is to make use of the fact that, in Tcl, the backslash character works as a line continuation indicator, even within comments. So instead of:
#! /usr/local/bin/tclsh
puts "Hello World"
You could use:
#! /bin/sh
# The next line is executed by /bin/sh, but not Tcl \
exec tclsh $0 ${1+"$@"}
puts "Hello World"
and the script will run regardless of where tclsh is located (as long as it is in one of the directories in the user's PATH).
Often people ask why some language extension that they use often (in fact, they may find it indispensible) isn't merged into the core language.
It must be remembered that a lot of people use Tcl on widely differing systems and in vastly different ways. Also, Tcl was originally intended as an embedded language that would provide the minimal programming constructs and framework upon which a programmer could base the scripting language for their application.
Having said that, the core Tcl language has grown over the years. Some of the added features have come from extensions written by others. When the capabilities provided by extensions are deemed to be of sufficient value to all users of Tcl, John has added them to the base language. Some examples are associative arrays, the file I/O commands (and file handles), and the unknown procedure, all of which appeared in Extended Tcl before becoming part of standard Tcl. Tk 4.0 and later contain the equivalent functionality of the addinput and photo widget extensions that were written by others for Tcl 7.3/Tk 3.6.
Use arrays or Extended Tcl keyed lists.
For example, if you did a:
keylset ttyFields ttyName tty1a
keylset ttyFields baudRate 57600
keylset ttyFields parity strip
And then an echo $ttyFields, you'd get:
{ttyName tty1a} {baudRate 57600} {parity strip}
Or using arrays:
set ttyFields(ttyName) tty1a
set ttyFields(baudRate) 57600
set ttyFields(parity) strip
Tcl 8.0 includes a random number generator
as a function in the expr command (one is also available
in Extended Tcl as a standalone command and has been for quite a while).
For example, to generate a random number between 0 and 9 inclusive:
set random_number [expr int(rand()*10)]
To get a value you can use as a seed (by calling srand()),
you might try one or a combination of these:
[pid]
[file atime /dev/kmem] (Unix only)
[clock seconds] (Tcl 7.5 or newer)
[clock ticks] (Tcl 7.5 or newer)
The last of these is used, by default, if you do not specify a seed.
For older Tcl releases, there are several pseudo-random number generator functions, written in straight Tcl, that have been posted to comp.lang.tcl, see Larry's tcl-faq/part4 for a list.
Here is one that is syntax compatible with the one in Extended Tcl, but implemented in standard Tcl. The constants are from Don Libes. Be aware that there is little checking for valid arguments and that the default seed value only works with Tcl 7.5 or newer.
proc random {args} {
global RNG_seed
set max 259200
set argcnt [llength $args]
if { $argcnt < 1 || $argcnt > 2 } {
error "wrong # args: random limit | seed ?seedval?"
}
if ![string compare [lindex $args 0] seed] {
if { $argcnt == 2 } {
set RNG_seed [lindex $args 1]
} else {
set RNG_seed [expr \
([pid]+[clock ticks])%$max]
}
return
}
if ![info exists RNG_seed] {
set RNG_seed [expr ([pid]+[clock ticks])%$max]
}
set RNG_seed [expr ($RNG_seed*7141+54773) % $max]
return [expr int(double($RNG_seed)*[lindex $args 0]/$max)]
}
Assuming y requires multiple args and x returns multiple words, use Tcl's eval command:
eval y [x]
Use upvar rather than try to use global variables when possible. If the function is event driven, you are forced to use global variables.
# print elements of an array
proc show_array arrayName {
upvar $arrayName myArray
foreach element [array names myArray] {
puts stdout "${arrayName}($element) = $myArray($element)"
}
}
set arval(0) zero
set arval(1) one
show_array arval
To return an array from a procedures, just take the array name in as an argument, as above. Any changes you make in the array will be made in the parent's array as well.
Extended Tcl introduces a concept called keyed lists which are arrays made out of lists of key-value pairs and can be passed by value to routines, over networks, etc.
For example, to grep a pattern out of a range of files, one might do:
Karl Lehenbauer (karl@NeoSoft.com) writes:
set files [glob /home/cole/stats/*]
proc parseInfo { site } {
global files
#
# site is chosen from a listbox earlier
#
set in [open [concat "|/usr/bin/grep $site $files"] r]
while {[gets $in line]>-1} {
puts stderr $line
}
catch {close $in}
}
One thing: the matching strings are not returned in directory order.
But what if I want to check the return code AND use the output of the command? Kevin B. Kenny (kennykb@dssv01.crd.ge.com) writes:
if [catch {exec ls} data] {
# The exec got an error, and $errorCode has its termination status
} else {
# The exec succeeded
}
# In any case, `data' contains all the output from the child process.
Note that Karl Lehenbauer (karl@NeoSoft.com) adds that errorCode will be a list containing three elements, the string "CHILDSTATUS", the process ID of the child, and the exit status of the child.
Rename the procedure to have no name, for example:
rename procedureName ""
Set the global variable tcl_precision to a value in the range 1-17. For example:
% expr 4*atan(1)
3.14159
% set tcl_precision 0
can't set "tcl_precision": improper value for precision
% set tcl_precision 3
3
% expr 4*atan(1)
3.14
% set tcl_precision 16
16
% expr 4*atan(1)
3.141592653589793
% set tcl_precision 18
can't set "tcl_precision": improper value for precision
In Tcl 8.0 this value defaults to 12, in 7.x, the default is 6.
The procedure unknown is called automatically with arguments containing the command and its arguments for any command that couldn't be found. In fact, Tcl and Extended Tcl use this feature to provide demand loaded commands, and even entire libraries. Also, when using the "tclsh" or "tcl" shells interactively, the unknown procedure enables the shell to run external programs (i.e. without typing "exec" first).
So by modifying the unknown procedure you can provide your own extended functionality, or even remove the demand loading capability if you so desire.
By using something like the following.
set olddisplay $env(DISPLAY)
set env(DISPLAY) unix:0
Thanks to Joel Fine (joel@cs.berkeley.edu) for the answer.
You can also check if an environment variable exists, like this:
if [info exists env(VARNAME)] {
# okay, it's there, use it
set value $env(VARNAME)
} else {
# the environment var isn't set, use a default
set value "the default value"
}
In Tcl, numbers that start with a zero are interpreted as octal values (or hexadecimal, if the zero is immediately followed by an 'x'). Often, this is a useful feature, but there are some problems:
Prior to Tcl 7.4b3, the interpreter would try to interpret a number such as 08 as a floating point value. Starting with 7.4b3, the interpreter generates an error message when presented with such a value.
You have to strip off the zeros. Here are two possible implementations of a function "stripzeros":
proc stripzeros {value} {
regsub ^0+(.+) $value \\1 retval
return $retval
}
or
proc stripzeros {value} {
set retval [string trimleft $value 0]
if { ![string length $retval] } {
return 0
}
return $retval
}
Then, whenever you are passing a value to a command that requires an integer value, and there is the possibility that the value has a leading zero, just pass it through this function first, i.e. instead of:
set dayofweek [expr $days%7]
use:
set dayofweek [expr [stripzeros $days]%7]
The program name is assigned to the global variable
argv0 and any arguments to it are placed in the
global variable argv as a list. The variable
argc is set to the number of elements in the list
argv. As an example:
#! /usr/local/bin/tclsh
if { $argc != 2 } {
puts stderr "$argv0: Usage: $argv0 <infile> <outfile>"
exit 1
}
set infile [lindex $argv 0]
set outfile [lindex $argv 1]
Sometimes people find that Tcl behaves differently than they expect (often because of the way some other language acts in a similar situation). They then think this unexpected behavior is a bug. Probably the most common occurance of this is in regard to comments.
In Tcl, everything passed to the parser must have proper list structure, even comments (and yes comments are passed to the parser, unlike in some languages where they are stripped at an earlier stage). Generally, this means you need to make sure your braces are evenly matched, even though they may be on a line that is commented out.
So, for example, you have an if statement that tests a certain
condition, but you want to try testing a different condition.
You comment out the old condition and type a new if statement.
This code will cause an error that there is a
missing close-brace:
## WRONG
if { $newflag } {
# if { $oldflag } {
puts hello
}
In this case, you have to balance the braces, for example:
## CORRECT
if { $newflag } {
# if { $oldflag } {
puts hello
# }
}
Another interesting point about comments in Tcl is that the line continuation mechanism still applies, so:
# This is a comment line that ends with a backslash \
and this line is still part of the comment
In Tcl 8.0, binary I/O is fully supported; just make sure the channel is configured for binary mode (see the fconfigure.n man page).
In 7.x and older releases, the Tcl interpreter stores nearly everything internally in null-terminated strings. This procludes the possibility of directly storing binary data (or more specifically, anything with embedded nulls).
However, certain operations can be performed without the data being stored in Tcl variables. For example, file handles can be attached directly to external programs, like this:
set infp [open "|compress -dc $fileName"]
exec gzip -c $newFileName <@ $infp
or in Extended Tcl:
set infp [open "|compress -dc $fileName"]
set outfp [open "|gzip -c $newFileName" w]
copyfile $infp $outfp
In Tcl 7.6, you can copy binary data between open channels using the command unsupported0. However, as is indicated by the name, it is not a method which should be relied on - it will disappear in a future release, although proper support for handling binary data should be added at that time.
Alternatively, you can in some way convert the data to a form that is usable from Tcl:
Thanks to Wayne Throop throop@aur.alcatel.com for his contribution to this section.
Extended Tcl offers many of these types of functions. For instance, extended Tcl has the signal command:
signal action siglist [command]
where action is one of "default", "ignore", "error", "trap", "get", plus the POSIX "block" and "unblock" actions (available only on POSIX systems, of course). Siglist is a list of either the symbolic or numeric Unix signal (the SIG prefix is optional). Command is your error handler (or a simple {puts stdout "Don't press *that* key!"} :-) trap does what you expect, and I find error and get to be extremely useful in interactive programs which demand keyboard traversal.
Extended Tcl also has things like fork, etc.
Answer by Brad Morrison (brad@NeoSoft.com).
There is one and only one level of substitution possible
with every pass through the interpreter. Also, when doing
variable substitution, the interpreter finds the dollar sign and
then takes everything following it up until the next invalid
character (where invalid is defined as anything other than a letter,
digit, or underscore) as the name of the variable - well, that is,
unless it finds array notation or the ${varname} form.
In the case of $$var, the character after the first
dollar sign is an invalid character (another dollar sign), so there
is no variable name and variable substitution is not performed (the
dollar sign is left as is) and scanning starts again for any dollar
signs and a following variable name. It is immediately found at
that second dollar sign, the substitution is performed, and scanning
for dollar signs resumes with whatever was after the variable name.
Since there isn't anything else, substition is done for this pass
through the interpreter (remember it's only done once).
The eval command runs its arguments through
the interpreter, so you could use
eval to cause a second pass through the interpreter,
and thus, have $$var work:
% set a 5
5
% set var a
a
% puts $$var ;# This doesn't work
$a
% eval puts $$var ;# This does - but it's dangerous
5
However, if the contents of var contain any special characters (e.g. whitespace, semicolon) you'll run into problems.
A better method is to take advantage of the behaviour of
the set command when given only one argument, and
combine command substitution with variable substitution:
% puts [set $var] ;# This works safely
5
or, in fact, you could use just command substitution (which is performed once for each [ ] pair):
% puts [set [set var]] ;# as does this
5
Similarly, to print the values of var1, var2, and var3:
set var1 3.14159
set var2 hello
set var3 13
foreach num {1 2 3} {
puts "var$num = [set var$num]"
}
will output:
var1 = 3.14159
var2 = hello
var3 = 13
The upvar command can also be used to derefence
variables.
In addition, starting with version 7.4, the interpreter includes
the command subst which can be used to perform
substitutions.
Note that all of the above applies to array variables also.
A long article dealing with the issues can be found at ftp://ftp.neosoft.com/pub/tcl/alcatel/docs/README.programmer.gz
Here are some short answers:
Q. I'm trying to build up a command for later execution but am having trouble with variable values that include whitespace or special characters.
A. The safest way to build up commands is to use the list command so that you can keep track of the list structure. Avoid using double quotes because you can end up with an extra trip through the evaluator. We'll illustrate this with a command to create a button that prints out the label on the button when you click it.
Wrong answer #1:
button $myname -text $label -command "puts stdout $label"Why? because if $label has whitespace then the puts command will be passed the wrong number of arguments. If $label has $ or [ ] characters, they will be interpreted instead of printed.
Good answer #2:
button $myname -text $label -command [list puts stdout $label]Why? because list will properly quote the value of $label
Q. I'm trying to build up a command for later execution but am having trouble getting some variables to evaluate now, and some to evaluate later when the command is run.
A. The cleanest way to do this is to define a procedure that hides the use of the variables at run time, and then build up a call to that procedure using the list command as described previously. (You can even define the procedure on the fly. It will have global scope even it if is created within another procedure.)
Wrong answer #1:
button $myname -text $label -command \ [list puts stdout $ArrayOfDynamicStuff($label)]Why? The array value will be substituted when the button is created, not later on when the button is clicked. Also, note that the command is executed at the global scope, so it is not necessary to include a "global ArrayOfDynamicStuff" in the command.
Wrong answer #2 (backquotes and list):
button $myname -text $label -command \ [list puts stdout \$ArrayOfDynamicStuff($label)]Why? Here the list command and the backquote of $ are fighting with each other. The command ends up being something like:
puts stdout {$ArrayOfDynamicStuff(foo)}which prevents the substitution of the value of the array element.
Dubious answer #3 (backquotes and double-quotes):
button $myname -text $label -command \ "puts stdout \$ArrayOfDynamicStuff($label)"Why? This only works if the value of $label has no special characters or whitespace.
Clean answer #4 (proc):
proc doit { i } { global ArrayOfDynamicStuff puts stdout $ArrayOfDynamicStuff($i) } button $myname -text $label -command [list doit $label]Why? Using little TCL procs for your button commands is a good habit because it eliminates most needs for fancy quoting, and it makes it easier to tweak the button command later on.
Q. I'm trying to pass along a variable number of args to another procedure but I'm having trouble getting the $args to expand right.
A. Avoid using eval and double quotes because that results in an extra trip through the interpreter. The eval command will do a concat of its arguments if there are more than one, so that pretty much eliminates the need to group things with double quotes. Let's extend the button example:
Wrong answer #1:
proc mybutton { myname label args } { button $myname -text $label -command [list puts stdout $label] $args }Why? All the extra arguments to mybutton are grouped into one list element that is but into the value of $args. However, the button command expects to see individual arguments, not a sub-list.
Wrong answer #2:
proc mybutton { myname label args } { eval "button $myname -text $label \ -command [list puts stdout $label] $args" }Why? The double quotes allow expansion of $label as well as $args, so if $label has any whitespace, the button command will be malformed
Good answer #3:
proc mybutton { myname label args } { set cmd {button $myname -text $label -command [list puts stdout $label]} eval $cmd $args }Why? Eval will first concatenate its two arguments and then run the result through the interpreter. Think of this as stripping off the outer curly braces from $cmd and $arg and making a single list with all the elements of both. $label will be evaluated exactly once, so the puts command will remain good, and whatever went into args will also be processed exactly one time.
Q. Why do I get a syntax error in an if/while/for statement?
A. You may have written something like
wish: set foo bar
wish: if {$foo == bar} {puts stdout bar}
syntax error in expression "$foo == bar"
in which bar is interpreted as neither a string nor a variable, since strings as operands in expressions MUST be surrounded by double quotes or braces.
Change to
wish: if {$foo == "bar"} {puts stdout bar}
or
wish: if {$foo == {bar}} {puts stdout bar}
always in expressions, depending on if you want expansion performed or not.
Contributed by Jesper Blommaskog (d9jesper@dtek.chalmers.se).
Rather than sourcing the files explicitly, build a tcl library:
Step 1. Put the files in a common directory
Step 2. Build the tclIndex for the "library". I use a Makefile with a convention like:
install.index:
(cd ${DESTDIR}/tclscripts/lib; \
echo 'source /usr/local/lib/tcl/init.tcl;\
auto_mkindex . *.tk' | tcl ; exit 0)
Step 3. Modify your tcl scripts to reference the library:
e.g.:
# local additions
lappend auto_path /usr/local/lib/tcl_local $env(RDS_TCL_SCRIPTS)/lib
Now, as soon as your script tried to reference a procedure in the library, the "unknown" command autoloads the procedure for you.
Contributed by Joe VanAndel (vanandel@ncar.ucar.edu).
A user asked why
linsert $list 0 ..
did not result in .. being inserted into list.
Jesper Blommaskog (d9jesper@dtek.chalmers.se) replied:
When doing list operations other than lappend, you must save the returned value. This applies to list, lindex, lrange, and lreplace at least.
In this example, you would perhaps want to do something like:
set list [ linsert $list 0 .. ]
From Frank Smith (frank@arraysystems.nstn.ns.ca) we are told that if you have Extended Tcl, you can
read $fileId [fstat $fileId size]
This will read only the number of bytes currently available on fileId and consequently will not block.
The stdio package has an optimization for speed that buffers characters so that you can avoid un-necessary system calls. This isn't very good for interactive use, so stdio changes its behaviour if the file is a terminal. When you write to a pipe you are not writing to a terminal and so your output is buffered, similarly when the program at the other end of the pipe writes its response it is also buffered. The end result is the programs at both end of the pipe stall waiting for input. It is possible to force the buffers to be written using flush in Tcl and fflush() in C, often though, you don't have control over the program at the other end of the pipeline and in that case your only solution is to use a pseudo-teletype (pty). Unfortunately this isn't all that easy.
While this isn't directly supported in Tcl, the spawn command in expect opens a pty and starts a command.
Well, there is no one answer to this. Tcl itself, will tell you its version, if you type:
puts $tcl_version
or in older versions:
info tclversion
To get the Tk version, use:
puts $tk_version
Other extensions use other means (for example, Extended Tcl
uses infox version to return its version number).
Starting with the 7.4 version, the tclsh executable is, by default, installed with the version number appended - making it rather obvious which version you are running. However, if it is not installed like that on your system, you can find out the version from the shell prompt with something like:
echo 'puts $tcl_version;exit 0' | tclsh
(the ;exit 0 part is only needed for wish and its
derivatives, but doesn't hurt anything when it isn't needed)
Eric Bleeker (ericbl@paramount.nikhefk.nikhef.nl) has written:
You may have written something like:
% set foo "bar baz" bar baz % foreach aap $foo { set $aap(1) "something" } can't read "aap(1)": variable isn't arrayThis means Tcl tries to substitute the array element aap(1) which doesn't exist. To fix this use:
% foreach aap $foo { set [set aap](1) "something" }In this case two arrays bar and baz are created.
An alternative format is:
% foreach aap $foo {
set ${aap}(1) "something"
}
The static keyword in C is used for different purposes. One of the most common is when you wish to have a variable that retains its value across invocations of the same function (but without making the variable globally available). Karl Lehenbauer (karl@NeoSoft.com) wrote the following procedure to emulate this behaviour:
proc static {args} {
set procName [lindex [info level -1] 0]
foreach varName $args {
uplevel 1 "upvar #0 staticvars($procName:$varName) $varName"
}
}
Another common use, is when you want a global variable that is only visible to functions within that particular source file. This is best handled by a namespace facility. Tcl does not yet have a built-in namespace facility, but several extensions are available the provide one. See the software catalog in Larry's FAQ for more info.
To get the ASCII value of a character:
proc toASCII { char } {
scan $char %c value
return $value
}
puts "The ASCII value of 'A' is [toASCII A]"
To convert from an ASCII value to a character:
proc toChar { value } {
return [format %c $value]
}
puts "The ASCII value 65 corresponds to the character '[toChar 65]'"
Some of the most commonly encountered problems with using the Tk toolkit are due to misunderstandings/misuses of Tcl. This section discusses some of them.
See also question B16 and the Tk 4+ Usage FAQ.
Each command in Tcl must have a proper list structure. The best way to ensure that is to use the list command to build the list. So, for example, instead of:
button .b -text "OK" -command "puts $message"
use:
button .b -text "OK" -command [list puts $message]
It gets a bit more complicated when you want to have multiple commands invoked. In this case, you need to have a string consisting of a list for each command seperated by a command terminator (a newline or semi-colon). An example:
button .b -text "OK" -command "[list puts $message]; [list exit 0]"
A more manageable way, is to wrap all of the commands into a separate procedure:
proc puts_msg_exit mesg {
puts $mesg
exit 0
}
button .b -text "OK" -command [list puts_msg_exit $message]
All of the suggestions given in the previous question apply here too.
Let's consider this example:
checkbutton .b -text "Foo" -variable myvar
The variable myvar will be interpreted as a
global variable. Therefore, if that line appeared
inside a procedure like this:
####### Wrong ########
proc setvar { arg1 arg2 } {
set myvar 1 ;# make the checkbutton start out depressed
checkbutton .b -text "Foo" -variable myvar
}
####### Wrong ########
the attempt to set the initial value of the checkbutton's state to
true would fail, because it is the local variable myvar
that gets set, while the checkbutton widget only pays attention to
the value of the global variable of the same name.
Simply inserting a global declaration will fix the problem:
####### Correct ########
proc setvar { arg1 arg2 } {
global myvar
set myvar 1 ;# make the checkbutton start out depressed
checkbutton .b -text "Foo" -variable myvar
}
Likewise, attempts to read the state of the checkbutton, via the variable myvar, must be sure to access it from the global scope or declare that the global variable is needed.
See also the next question.
Building on the example in the previous question, let's consider this code:
####### Wrong ########
proc setvar { arg1 arg2 } {
global myvar
set myvar 1 ;# make the checkbutton start out depressed
checkbutton .b -text "Foo" -variable myvar \
-command [list puts $myvar]
}
####### Wrong ########
This is intended to print out the state of the checkbutton whenever it
changes and since myvar is declared as global it should
work, right? No, whenever the checkbutton state changes, it will output
a 1. The problem is that the value of the variable is read
at the time the widget is created (well actually slightly before),
rather than at the time the state changes.
When that command is parsed, the first thing that happens is that the text $myvar gets replaced with the value of the variable myvar which at that point is 1, thus the line becomes:
checkbutton .b -text "Foo" -variable myvar \
-command [list puts 1]
So what is needed is a way to defer the variable substitution until the time the puts command is invoked. Using a backslash to escape the dollar sign will work:
checkbutton .b -text "Foo" -variable myvar \
-command [list puts \$myvar]
or you can wrap it in a procedure, like this:
proc puts_myvar {} {
global myvar
puts $myvar
}
checkbutton .b -text "Foo" -variable myvar \
-command puts_myvar
What if for some variables you need to use the value at the time of widget creation and for other variables you need the value at the time the widget calls the command? You can use a mixture of escaped and un-escaped dollar signs, but the wrapper procedure is usually more manageable, for example:
proc puts_variables {premesg postmesg} {
global myvar
puts $premesg $myvar $postmesg
}
proc make_checkbutton {after} {
set before "The value is "
checkbutton .b -text "Foo" -variable myvar \
-command [list puts_variables $before $after]
}
make_checkbutton " (where 1=true and 0=false)."
Here the variables before and after are local to the make_checkbutton procedure and myvar is global.
Whenever its state changes, the checkbutton widget will invoke the command:
puts_variables {The value is } { (where 1=true and 0=false)}
The puts_variables procedure will then get the
value of the myvar variable each time it is invoked.
This section lists some error messages and some possible (and non-obvious) reasons why you may be getting them.
This error message comes from your shell, not Tcl. The script probably starts with a #! that is followed by a path to the Tcl interpreter that is too long for your system. Many Unix systems are limited to 32 characters (including the #!) in this regard. So, something like this will fail:
#! /usr/home/homedir/very/long/path/tclsh
# rest of script
You can either shorten the path by moving the tclsh executable to a different directory or by using symbolic links. Another option is to not specify the path at all. See the question "How do I make my script executable regardless of the location of tclsh?" for an example of how to do this.
You have probably commented out a line that ends with an open curly brace. See Question B12 for more info.
Your braces aren't balanced. Again, one likely, though perhaps non-obvious, reason is improperly commented lines. See Question B12.
Tk requires you to have a secure X server before you can use the send command. See the question 2.A.7 "How can I get Tk 3.3 to even start - I get security error messages." in Thomas Accardo's Tk Toolkit Usage FAQ as well as http://ce-toolkit.crd.ge.com/tkxauth/ for instructions on how to make your server secure.
This error occurs when trying to perform some mathematical operation that requires an integer value, but given a non-integer value. While this is pretty obvious when the value supplied is a floating point value or an alphabetic string, this error can be confusing when the value is something that may look like a valid integer. Specifically numbers that have leading zeros. See the question How can I use numbers with leading zeros? for an explanation.
If when linking an application you get an error saying that the
main function was not found, it is probably because the
application was written for a version of Tcl prior to Tcl 7.4 and
you are linking it with version 7.4 (or later).
Older versions of Tcl included a main
function in the library (libtcl.a).
This caused various problems, in particular with C++
programs, and it was removed starting with version 7.4b1.
The application being linked with the Tcl library must now provide
the main routine itself.
This section contains some hints on compiling the Tcl distribution on various platforms and other notes regarding platform specific problems.
For building Tcl 7.4 and newer releases, there is now an on-line database, maintained by Sun, for people to query, if they have problems building the standard distribution. If the software did not build automatically for you, check at http://www.sunlabs.com/research/tcl/ for an entry regarding your platform. And please share your experience, if there is no current entry and you were able to get the distribution to build somehow.
Notes that were previously listed here, but which apply primarily to older releases are now available in a separate document at: http://psg.com/~joem/tcl/PlatformNotes.html
See also Question A2
glob cut off the first two characters of each filename?This problem can occur on SVR4, Solaris 2.x, and similar systems that have both System V and BSD libraries. It happens when the interpreter is compiled with include files that don't match the libraries to which it is linked (specifically, readdir returns a different structure than is expected). You need to modify the Makefile to make sure the include files correspond to the libraries.
For Microsoft specific information see the FAQ maintained by Eric Foster-Johnson (erc@pconline.com). It is available at: http://www.pconline.com/~erc/tclwin.htm
This is now supported for some platforms in the standard distribution.
You can also get the "Plus" patches, which include support for additional platforms. For more information, see http://www.nici.kun.nl/tkpvm/pluspatch.html
Additionally, Extended Tcl includes instructions for building shared libraries on many Unix systems. You may be able to use this information, if your platform is not supported by the plus patches.
Send comments regarding this page to Joe Moss (jmoss@ichips.intel.com)