Tcl workers 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 command ''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]". ---- .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. ---- [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] ...). * On Unix, [auto_execok] does its search for executables in the directories of PATH, yes, but [exec] does not call [auto_execok] internally. * On Windows, the search is guided by PATHEXT, PATH, and WINDIR. See tcl/library/init.tcl or [Secrets of the init.tcl library file] for details. 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] ---- '''Bad magic (taboo names)''': You should not call a toplevel source file 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... ----- See also [stdin], [stdout], [stderr]. ---- ! How could we have failed to mention [args] , [argv], and [argv0] until now? ---- Other special names are the global arrays [env] and [tcl_platform]. ---- See also [Tcl syntax help] - [Tk syntax help] ---- [Category Porting]