This page is intended as a discussion platform with the goal to possibly obtain a console behaviour improvement to being proposed as a TIP.
Refer also to LV's question here: console
In both cases discussed below, it must be differentiated between invokes from a native OS's console and invokes from e.g. a desktop icon.
Called from a native console, the platforms uniformly behave identically whether tclsh is called with or without a script as an argument. (Note question [L1 ] about Windows tclsh misbehaving when run under third-party console.)
In this case, the console command is not available by default.
On Linux/Unix, the stdout and stdin needs of the tcl program will be met in the console window where the program was invoked.
Under Windows, tclsh can be started from outside a console window - for example, from a shortcut, or from the Start menu. However, the console command is still not available.
On linux/unix, the console command is never available, regardless of how Tcl is started. The stdout and stdin for the program will not be accessible in this scenario.
On MacOS X, tclsh is not an application, and thus cannot be started as such (double-clicking icon raises dialog "please locate application to open tclsh with").
When starting Tcl via wish, major differences will occur:
Here, the behaviour differs through OS'es when invoked without argument: windows and MacOS X creates a Toplevel AND a console, Linux/unix creates only a toplevel. Just as in the parallel case of launching a Tcl program from an icon on linux/unix, the stdout and stderr for the program are not accessible.
Having stated this, it seems that there have been mentions regarding the fact that, with dynamic loading of Tk now possible, the use of WISH should be deprecated. MHo On MS Windows, calling WISH oder first TCLSH then requiring Tk is not the same. In the latter case the console window remains open, or if started from explorer etc. first a command windows opens, then the application window. Which is not wanted in most cases.
This would imply that "the" simple way to invoke an interactive console in scripts running under Windows should be deprecated, too (i.e. the console command).
LV I don't understand this last sentence.
(These ideas are noted without commenting them in terms of value)
Idea 2 might be problematic, because the native shell is still active while processing tclsh + argument. But perhaps a way can be found. However, for some system constellations this idea is very valuable. E.g. in systems with a console device separated from a graphics device. Example: Embedded systems where a Tk app should start automatically after power-up. A remote console via serial port allows hooking in a running application when necessary. Without forcing interactive mode, remote introspection is possible only by killing the Tk-app, and then start it in two steps: tclsh + source xxx.
(further comments and ideas are welcome)