'''[http://www.tcl.tk/man/tcl/UserCmd/tclsh.htm%|%tclsh]''', or '''Tcl Shell''', is a [shell] for the [Tcl] interpreter included in the [The Tcl Core%|%Tcl Core] distribution. ** See also ** [tclsh vs. wish]: ** Description ** When '''tclsh''' (including [wish]) reading commands from a terminal, it is in interactive mode. When it is reading commands from a file, it is not. Interactive mode can also be enabled by setting '''`[tcl_interactive%|%$::tcl_interactive]`''', to '''`1`''', or disabled by setting it to '''`0`'''. Here are behaviours that depend on interactive state of tclsh: '''`[unknown]`''': If the missing command is an unambiguous abbreviation for another existing command, `unknown` invokes that command instead. Commands beginning with `!` or `^` may also be subject to [history] [Dodekalogue%|%substitution]. `unknown` executes `[exec]` passing it the words of the command. Setting '''`[auto_noexec%|%$::auto_noexec]`''' to '''`1`''' suppresses this behaviour. When thee state is not interactive, '''`[unknown]`''': Raises an error. '''Prompting''': The result of each command is displayed on [stdout] followed by a '''`%`''' indicating that the interpreter is waiting for the more input. When not in an interactive state, the interpreter simply discards the results of each command in the script. '''byte-compilation''': Commands typed at a prompt are [bytecode%|%byte-compiled]. Commands in a script are not byte-compiled ''([AMG] asks: is this still true?)''. Changing [tcl_interactive] has no effect on this. People writing scripts to be loaded from the ''tclsh'' command line should be aware that [\u001a is an end-of-file character in scripts]. ** Executing ** To evaluate a script from [stdin] while also providing `$argv` arguments: ======none tclsh - arg1 arg2 ====== ** Miscellaneous ** Isn't there some difference in the [source%|%sourcing] 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 unsuable'' mean, and how does such a state happen? ======none rob@rob-desktop:~$ tclsh % pwd /home/rob % ^[[A <--- here the cursor UP key is pressed ^C rob@rob-desktop:~$ ====== [LV]: Ah - because the tclsh interpreter itself doesn't try to deal with function keys, the original poster was finding that at times the escape sequence would leave his/her terminal window in a state where even returning to the shell prompt was insufficient to reset the terminal settings. While I've not seen this myself, I certainly would understand the circumstances the original poster might have encountered. [EW]: The following program 'readline front-end' provides input line-editing for any program that does not provide their own. Running 'rlfe tclsh' for example will allow the arrow keys to work and also seem to fix backspace issues. http://per.bothner.com/software/rlfe-0.4.tar.gz [MPR]: Some linux distributions also include a rlwrap package. Running 'rlwrap tclsh' or similar provides line editing and history. ---- ''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. Well I ([RJM]) belong to those ''some'' who has been stuck by the absence of command history in Linux/Unix. This is due to years of Tcl experience in a Windows environment and a recent switchover to Linux. Meanwhile I found that GNU "readline" support would include command history - query wiki pages with "readline" in page title... Regarding the TIP proposal: I'm not going to do a proposal without having verified that things are indeed behaviouring as suggested - I could also have been overlooking just other implementation of a feature like command history. At this time I'm going to investigate the relevant wiki pages before doing so. Well, result of this investigation (after a longer time of ignoring the problem): readline availability via debian/ubuntu apt-get, info added at [tclreadline]. I think one of the two major objections against tcl that can be read about in the following '''excellent''' article is no longer an objection [http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong]. [HE] 2019-08-30 Remark: In the paragraph 'Prompting' it is mentioned that "The result of each command is displayed on stdout" and "When not in an interactive state, the interpreter simply discards the results of each command in the script". It could be, that I have a wrong understanding of "result of a command" and the "return value of a command". From my point of view the result is what the command is supposed to do. The return value is what the command is supposed to provide to the caller in relation to the success of its function. An example: The command open is supposed to open a file, serial port, or command pipeline according the given parameter. Its return value is, in case of success, a channel identifier or in the other case a Tcl error. With this, it is wrong to say the result is displayed on stdout. Or, discarded in case tclsh is not in interactive mode. I'm pretty sure that the file would be open, in my example, even if not in interactive mode ;-) [PYK] 2019-09-02: [Dodekalogue%|%Tcl rule 7] uses "result" to refer to the [value] that a [command] [return%|%returns], and that term is used throughout the [https://www.tcl-lang.org/doc/%|%documentation] to mean the same thing. Things that "happen" in the process of carrying out a [routine] are traditionally referred to as "effects", and in [functional programming] are considered to not exist. That doesn't mean that a program written in a functional language can't "do" anything. Instead, it means that a work written in a functional language describes not the program, but a mathematical model, and the language implementation itself takes the initiative to interpret the model and build the corresponding program to [meta programming%|%make it so]. Tcl, [What is Tcl%|%odd duck] that it is, happens to fit the bill for a functional language. ---- [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."'' <> Application | Tcl | Platform Issues