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] ---- **Inventory** 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. ***1a. console invocation of tclsh*** Called from a native console (i.e. text based command line interface), the platforms uniformly behave identically whether [tclsh] is called with or without a script as an argument. (Note question [http://wiki.tcl.tk/21076#pagetoc216e9d5d] about Windows tclsh misbehaving when run under third-party console.) In this case, Tk's console command is not available by default. Under Linux/Unix/MacOS, the [stdout], [stderr] and [stdin] needs of [tclsh] will be met in the command line text window where tclsh was invoked. Under Windows, [[fill in the details here]]. ***1b. tclsh invocation from icon, etc.*** Under Windows, tclsh can be started from outside a console window - for example, from a shortcut, from the Start menu, or from the Run dialog. However, the console command is still not available. On Linux/Lnix, 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. Tip 561 [https://core.tcl-lang.org/tips/doc/trunk/tip/561.md] is now published to add the console command to linux/unix type systems. It uses the code here [https://wiki.tcl-lang.org/page/console+for+Unix] to enable the console on systems that don't have a console command defined. It's still a work in progress as of 1/27/20. It will delay the invoking of that wiki code until the first console command is issued, which leaves stdout/stderr as is if the console command is not used. On MacOS X, tclsh is not an application, and thus cannot be started as such (double-clicking icon raises the dialog "please locate application to open tclsh with"). ***2a. console invocation of wish*** When starting Tcl via [wish], major differences will occur: * The command "console" exists, but only under Windows. * Under Windows, a Tk-based console is opened together with a Toplevel window * On Unix/Linux, the console command does not exist. Output to stdout or stderr will appear in the command line text window where wish was invoked. * Under MacOS X, Tk opens the console as with tclsh, with a Tk toplevel created. ***2b. wish invocation from icon etc.*** Here, the behaviour differs through OS'es when invoked without argument: Under Windows and MacOS X, Tk creates a Toplevel AND a console, while under Linux/Unix Tk creates only a toplevel. Just as in the parallel case of launching a Tcl program from an icon under Linux/Unix, the stdout and stderr for the program are not accessible. Having stated this, it seems that the use of WISH as a working tcl console should be deprecated, because it represents another workflow compared to the Linux/Unix workflow. 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 show command). ***3. starting Tk apps *** When Tk apps are to being invoked from an icon click or whatever comparable thing, opening with an underlying tclsh always opens the GUI and a text-based console, which is normally not desired. In fact this is the only case where WISH comes in as a necessity: for starting apps without an extra console. Windows then, offers the feature of showing a Tk-console on the fly (sure, the ability to introspect a long running program on the fly can be handy - however at the cost of efficiency: programs having quite a lot of [puts] output are slowed down in execution speed when the console is hidden). When console-based introspection is required, the app should be started via tclsh. From these considerations follow that every Tk program should include a "package require Tk" line (in some - if not many - real-world programs, it is not present, due to extensive use of wish also as the working console amongst windows users. ---- **Ideas for portability improvement** (These ideas are noted without commenting on them in terms of value.) 1. A console command restricted to WISH invoked with 'script' as an argument (without script, this would contradict with the existing console). '''console show''' should create a Tk-based console. 2. An extra command line option with tclsh could help eliminate the need for a console command: -i, for interactive. This would force interactive mode, allowing introspection on running scripts (as is equally possible with '''console show'''). In contrast to the '''console''' command, the console window is visible/present all the time, which may be undesired. 3. package require Tk automatically creates a hidden Tk-based console, when not already present (as is the case in Windows). ---- 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) <<categories>> Command | Platform Issues