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. ---- See also [Tcl syntax help] - [Tk syntax help] ---- [Category Porting]