console platform portability

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 [1 ] 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.

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)