Version 18 of Magic names

Updated 2004-12-01 20:23:29 by lwv

Tcl developers often first encounter special keywords when confronted with a situation where the same application behaves differently for two different users/hosts/... For example, distinct auto_path-s can lead to loading of subtly different packages, which ...

[More motivation.] "tclvars" covers a different but related territory, that of particular variables (as opposed to files or commands) that influence Tcl. Let's don't list specific variables here just for listing - use the tclvars page for that. However, if there are other magic files or commands which make use of the variables, then a mention here, as well perhaps as a cross reference over on tclvars, makes sense. I just prefer not to see data scattered across the various pages haphazardly.


Tcl global variable auto_path [overloaded since 7.5--an understandable historical mistake]


Tcl file pkgIndex.tcl: package currently searches auto_path for files named "pkgIndex.tcl". More precisely, [... tclPkgUnknown ...]


Tclsh file .tclshrc

Note that the ~/.tclshrc file (~/tclshrc.tcl on Windows) are special values given by tclsh to the global variable tcl_rcFileName. The value of $::tcl_rcFileName is only special to applications like tclsh that call Tcl_Main(), not to Tcl itself. More on this subject appears in "The RC File".

LV I seem to recall seeing a discussion that indicated that the file in this variable is source'd in at start up time of an interactive tclsh script only - that if one runs the command

        tclsh somefile.tcl

that the $::tcl_rcFileName doesn't execute. Certainly that seems to be the case. However, if one does something like:

        echo "puts ABC" | tclsh

the rcFileName file is still source'd.


X Window system file .Xdefaults [... option ... ] This file would actually only be used, I suspect, by the X window system, which is used with the Unix specific portion of the Tk code (which probably also gets used on VMS and a number of other platforms). I don't THINK that Tk accesses this file directly. There are other files that X also access - I suppose that the X code in Tk searchs XFILESEARCHPATH and XUSERFILESEARCHPATH, doesn't it? What about the X Resource Database?

PT: This turns out not to be the case. If, under windows, you define HOME and create a %HOME%\.Xdefaults it will be used by Tk. A simple test is to create this file and just enter *Background: red then fire up wish and see a red toplevel widget.


TCLLIBPATH

An environment variable used to help Tcl find its shared libraries on unix systems. Some systems (like Linux) have other means of doing this.

LV What is the format of this variable? I always thought it was to be specified in standard Unix Bourne shell notation:

        export TCLLIBPATH=/some/path:/some/other/path

but recently noticed a claim that the real format should be

        export TCLLIBPATH="/some/path /some/other/path"

... in other words, csh format. Upon testing, I found the claimant is correct.

Also, what specifically happens if this variable is found by a Tcl interpreter is that the values of the variable are prepended to the auto_path variable.


exec may use PATH, if the invocation of exec uses a relative path or simple command name to run. If a fully qualified pathname of the command is used, PATH is not referenced. Does this happen on MacOS and Windows as well?

  • Yes it does. Also, on Windows, the extensions .com, .exe, and .bat are magically applied to the executable name.

(or maybe it's really auto_execok ...).

What about VMS and other non-Unix/Windows/MacOS operating systems?

DKF: auto_execok is part of the machinery of code that is used to parse interactively-typed commands; while it does path searching, it really does more than that (like handling the bizarreness of shell commands on DOS/Windows, etc.) It returns a list of words to substitute (in a loose sense) in place of the command name when passed to exec, or an empty string if the word does not refer to anything executable.


errorCode describes the tcl variable containing results of an exec.


Bad magic (taboo names): When you create a toplevel, do not give it the same name as one any of the script source file names (like a widget), e.g. button.tcl, as is explained in Is there anything I should know before I start coding.

You should not call a procedure ".", if it is to run in a wish - it will, on definition, destroy the toplevel window.

DKF: Remember that images are also commands, so calling them things like "open" is a bad idea. Absolutely do not create an image called "." as that causes really bad things to happen. The easiest way to work around this, of course, is to let Tk pick the names for all the images it creates, and for you to store those names in an array indexed by the names that you prefer. Like this, you can be sure you won't hit things unexpectedly. (Also it means that you can use the same "names" to refer to different images in different contexts just by changing the name of the lookup array, which can make programming easier. You could even use read traces to populate the arrays on-demand...

LV Most Tcl and Tk commands create objects by the name provided by the developer/user, without regard for whether an item by that name already exists. This is as it should be, in most cases, since you don't want to have to use unset before every set command, now do you ?


See also stdin, stdout, stderr.


Some other magic variable names for Tcl are args , argv, and argv0, as well as the global arrays env and tcl_platform.


Canvas tags may be almost any strings - except: all, current, or decimal integers, or containing "&&" , "!", or "||", which imply logical handling of tags.


See also Tcl syntax help - Tk syntax help


Category Porting