tclsh is an application created by default by the core distribution of [tcl]. It is a simple shell interpreter, and is frequently used by developers for writing and executing tcl scripts. A user of tclsh (or of [wish], the interactive tcl shell with Tk automatically loaded), should be aware that there are a few differences between typing tcl statements to the shell in interactive mode and saving tcl commands into a file and then asking tclsh to execute that command file. The differences between tclsh in interactive mode and command file behavior include: 1. the [tcl_interactive] variable interactive: this variable is set to 1 command file: this variable is set to 0 The value of this variable is what actually controls several of the following behaviours — changing it will also change the behaviour. 2. [unknown] [proc] differences - if tclsh is unable to recognize a command, the unknown proc is invoked. interactive: unknown will automatically pass the command string to [exec] . command file: unknown will raise an error. The coder must code '''exec''' before any non-tcl commands. This difference is because the code in [unknown] that does this is conditionalized by the existence of the [tcl_interactive] variable, and that this is set to boolean true. It can be selectively turned off by defining the [auto_noexec] variable, however. 3. command abbreviations interactive: the unknown command looks to see if the typed command is an unambiguous abbreviation of an existing command and, if it is, invokes it. Thus in interactive mode it's possible to write set fp [op $myfile] : and see tclsh execute the [open] command. Commands beginning with ! or ^ may furthermore be subject to [history] substitution. command file: coder is required to write the string '''open''' out in full. This is covered by the same test in [unknown] as the previous item. 4. standard output displayed interactive: after tclsh executes a command, it writes the value of that command to the user's stdout screen. command file: the coder must code a [puts] to get the output from a command to display to the stdout screen. This happens because [tcl_interactive] is linked to the C level variable which controls this behaviour. 5. byte-compilation interactive: commands typed at a prompt are byte compiled command file: top level commands (ones not coded within a proc) are not byte compiled This is depends on the C functions used for evaluating the commands — effectively where the commands are being read from. Changing [tcl_interactive] has no effect on this. ---- Isn't there some difference in the [source]ing of .tclshrc ? ---- It should be noted that some behavioural details differ whether a windows console (tclsh) or a linux/unix console is used. E.g. command history: The arrow up key allows for browsing through commands in windows. In unix/linux, however, this has no effect. More than this: the console may be unusable for the active session, forcing one to restart the console. [LV] Can whoever wrote this last statement elucidate on their meaning? What does "console may be usuable" mean, and how does such a state happen? rob@rob-desktop:~$ tclsh % pwd /home/rob % ^[[A <--- here the cursor UP key is pressed ^C rob@rob-desktop:~$ ---- ''Q: Are those differences between tclsh on one hand and [wish] on the other, or is it between tclsh/wish run with a controlling terminal or without a controlling terminal? What about the [console] command?'' The wish and tclsh interactive input prompt in Linux/unix behave exactly the same (wish additionally opens a Tk toplevel automatically). "Without controlling terminal" makes no sense in terms of behaviour, simply because the terminal is absent (or is the question prone to false interpretation? - then please edit and remove this sentence). Console command: in a few words: exists only on Windows/Mac platforms. ''The first paragraph is highly unclear, so clarifications are needed, but not so much have been given so far. It also seems strange that "without a controlling terminal" might be viewed as less correct than "terminal is absent" — technically this is just the case that isatty(0) (in tclMain.c, function [Tcl_Main]) returns false. Yes, information about these things is needed, but what has been said so far seems overly simplified and not entirely correct.'' For more detail - on Windows (and MacOS X, perhaps), the Tk [console] command opens a unique window which provides command history. On X11 systems, it was assumed (not necessarily correctly) that Tk applications would be started from a command line and so no such thing was needed. Some feel that having a common behavior on all platforms for stdin/stdout/stderr interaction with Tcl or Tk (which would include command history) would be a useful enhancement. I don't know, however, whether any of those ''some'' have proposed a [TIP] and the work necessary to make that happen. ---- People writing scripts to be loaded from the ''tclsh'' command line should be aware that [\u001a is an end-of-file character in scripts]. ---- [Leibniz] would have loved an interactive tclsh: ''"Es wird dann beim Auftreten von Streitfragen für zwei Philosophen nicht mehr Aufwand an wissenschaftlichem Gespräch erforderlich sein als für zwei Rechnerfachleute. Es wird genügen, Schreibzeug zur Hand zu nehmen, sich vor das Rechengerät zu setzen und zueinander (wenn es gefällt, in freundschaftlichem Ton) zu sagen: Laßt uns rechnen."'' ---- [tclsh vs. wish] ---- !!!!!! %| [Category Application], a part of the [Tcl] package | [Category Platform Issues] |% !!!!!!