tclsh , or Tcl Shell, is a shell for the Tcl interpreter included in the Tcl Core distribution.
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, to 1, or disabled by setting it to 0. Here are behaviours that depend on interactive state of tclsh:
People writing scripts to be loaded from the tclsh command line should be aware that \u001a is an end-of-file character in scripts.
To evaluate a script from stdin while also providing $argv arguments:
tclsh - arg1 arg2
Isn't there some difference in the 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?
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 [L1 ].
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: Tcl rule 7 uses "result" to refer to the value that a command returns, and that term is used throughout the 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 make it so. 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."