A gotcha is an unexpected side effect, behavior, consequence, requirement, etc.
As with any language, the syntax and semantics of Tcl can catch the programmer off guard. This page is an attempt to enumerate constructs and behaviours that can be construed as gotchas, and is somewhat arranged by prominence and severity.
Twylite 2012-12-12: Setting a variable in a namespace eval can clobber a global variable. See Dangers of creative writing.
set foo 10
namespace eval bar { set foo 20 ; set bar 30 }
puts $foo ;# puts: 20
puts $bar ;# error: can't read "bar": no such variableAnother Tcl gotcha is to hand arbitrary strings, read from the user or a file/command, directly into a list operation without first ensuring that the contents is, in actuality, a list.
DKF: The best way to deal with such user input, where users aren't expecting to write a Tcl list in the first place, is to use a sanitizing command to convert the input into a proper list. Examples of sanitization commands can include split, splitx and (my favorite) this:
set elements [regexp -all -inline {\S+} $line]RS One possible gotcha is switch -- always use "--" before the switch variable, since if the value of the switch variable starts with "-", you'll get a syntax error.
AMG: This isn't required by Tcl 8.5 onward.
KPV Also, comments w/i switch, while possible, are tricky.
RS 2010-05-10: A similar gotcha is in the text search subcommand - although the misunderstanding could be avoided by counting non-optional arguments from the end,
set whatever -this $t search $whatever 1.0
raises an error that -this is an undefined switch. For robustness, use
$t search -- $whatever 1.0
if the slightest possibility exists that $whatever might start with a dash.
RS 2010-02-24: Yet another gotcha we ran into last night: Consider a function
proc f x {
if {$x == 00000000} {
puts "$x is NULL"
}
}which reported:
0E123456 is NULL
How so? Bug? No -- feature. With the == comparison operator, the operands are tried to match as integers, floats, or then as strings. And the $x in this case, though meant as a pointer in hex, could be parsed as float - with the numeric value of 0, which is numerically equivalent to 00000000. The solution of course was to use the eq operator instead.
AMG: Another issue with expr interpreting stuff happens when said stuff was already interpreted by Tcl. This creates performance, security, and correctness problems. Always brace your expr-essions!
Another example:
expr {{} < 0} ;# -> 1
expr {{} > 0} ;# -> 0
expr {{} == 0} ;# -> 0For the < and > operators, {} is interpreted as an integer, 0. For the == operator, 0 is interpreted as a string.
because
[string is] always returns 1 for the empty string. To avoid this, use -strict
The [string is] commands accept all the numeric notations that [expr] does (see The Octabug, so they aren't up to the job by themselves. Here is one way to do it:
set mynumber 0x11
expr {[string is entier -strict $mynumber] && [scan $mynumber %d mynumber] > 0}namespace eval table {
namespace export *
namespace ensemble create
}
proc {table::spoon fork} x {
return $x
}Even though there is no spoon, there is:
% puts [table spoon huh?] huh?
To change this behavviour:
namespace ensemble configure table -prefixes no