Version 28 of The (Few) Differences between Tcl and Tclkit

Updated 2010-08-10 13:52:30 by MHo

Purpose: describe to the implementor some of the things they must consider when using tclkit as his or her tcl base interpreter.

Intentional differences

  1. Tclkit includes additional extensions, which are detailed on the tclkit page
  2. Tclkit has fewer encodings than Tcl
  3. Tclkit has interactions with the VFS at times that make wrapping some Tcl extensions a challenge.

Unintentional differences (bugs?)

  1. glob appears to be broken inside of a tclkit. If you cd into the running tclkit, and then execute a glob on a string that does not exist anywhere on the machine, that string still is returned. PT: this appears to be a VFS bug. You can demonstrate it with non-tclkit tcl and vfs (at least with vfs::mk4). Vince: I don't see this problem (just tested) and neither do I see any bug reports on it.
  2. file permissions (and owners?) of files stored within a starkit are not (fully?) supported. Comments have been made in the past that this limitation/difference could be overcome with adequate additional code in the vfs type code. Vince: file permissions and such things are also not supported on Windows and MacOS classic.

KPV I've found two other differences that affected my scripts when running under wish or as a starpack:

  1. [info nameofexecutable] differs
  2. $argv0 differs

These are important because:

  1. Under Windows, how you associate an extension with your program differs. As a starpack you use [info nameofexecutable]; as a script, you must append $argv0 (after perhaps first fully qualifying it).
  2. Finding the directory containing your program differs (as a location to read or write files). As a script it is found at [file dirname $argv0]; as a starpack it is [file dirname [file dirname $argv0]]] (or as [info nameofexecutable]).

MHo: Performing (de|en)cryption yields different results with the same DES module wether driven by tclkitsh or tclsh (both 8.4.12):

 >tclsh cryptdiff.tcl test
 `↑á ¨A>D
 >tclkitsh cryptdiff.tcl test
 sú^?äØ?

What's that?????????? cryptdiff.tcl is:

 set auto_path [linsert $auto_path 0 [pwd]/des]; # ensuring specific des module
 package require des;
 set key {vnaspdou6134897(&%busdc/(%523egb75bfas#+s<c}
 puts [DES::des -mode encode -key $key $argv]

MHo: It seems to me that file executable did not work under Windows, at least for files inside the vfs.


MHo 2010-08-10: tclkit85's clock format shows a different time for the same value than Active State's base-kit 8.5 or regular tclsh:

D:\Home\Arbeit1\pgm\tcl\usr\prv\jpg\jpegcomment.test>tclsh85
% clock format [clock seconds] -format {%H:%M:%S %Z %z}
00:27:38 WAT +0100

and, a few seconds (!) later:

D:\Home\Arbeit1\pgm\tcl\usr\bin\tclkit>tclkitsh858
% clock format [clock seconds] -format {%H:%M:%S %Z %z}
01:29:34 +0200 +0200

What's this???

LV Can you give us details on the platform you are using, as well as where you got the tclkit? The reason I ask is that I tried the same tcl command on Solaris with a tclkit based on 8.5 and the clock worked fine there. However, I have confirmed that an 8.5 based tclkit that I ran on Windows XP behaved in the same manner as you describe.

It looks like something strange is going on in relationship to Windows.

MHo Tclkit is from http://www.patthoyts.tk/tclkit/win32-ix86/8.5.8/tclkitsh858.exe . Windows is WinXPSP3. More bizarre: Here, at work (same environment), the clock format works well (shown time equals FreeCommander/Explorer), but the %Z %z-Info again is "+0200 +0200".


See also Differences between tclkit and tcl, and Running starkits without Tclkit.