tclsh vs. wish

Differences include:

event loop
various memory usage patterns [?]
GUI service

Under MS-DOS or the Windows cmd.exe prompt,

    tclsh myscript.tcl > output.txt

does what one wants, but it's harder to achieve with wish.

Luciano ES Harder? Harder how? (please read on...)

LV Note that in comp.lang.tcl someone recently asked the difference, on Windows, between tclsh.exe and tclsh84.exe (and similarly between wish.exe and wish84.exe). The explanation is that the numbered exe's are copies of the unnumbered.

Why have both?

Well, the poster(s) expressed the opinion that for maximum portability, one would code their scripts using the unnumbered scripts.

Of course, the result of that is that when someone adds a new directory containing a different release of tclsh.exe in it, you may start having unexpected behaviors. Using the numbered versions would allow you to at least distinguish between the one level of release.

This topic was raised at comp.lang.tcl by Luciano ES who asked, boldly: "What do we need tclsh for?" My point was that wish can do everything that tclsh can, plus the extra optional features, so why not ditch tclsh and keep wish only?

Among the several mentioned reasons, were:

tclsh does not require a graphics server, like X. Also, tclsh uses a lot less resources than wish;
many applications that rely on Tcl/Tk are run on very low-spec hardware;
many (most?) applications do not need a GUI at all;
under Windows, tclsh has a console associated with it and it's the only way to see the various printf messages your code has under Windows, while wish doesn't force the MS-DOS text window, but instead allows one to execute the console command to optionally open a console;
Tcl makes very frequent use of event loops, which under Tk results in a probably unwelcome blank window being shown;
after processing a script, tclsh exits, while wish hangs around, entering the event loop;
LV adds: The very act of starting a wish begins by attempting to create and display a toplevel widget. For historical reasons, Tk has always created and instantiated a toplevel.

It was also noted that the opposite is a lot easier to achieve, i.e. ditch wish and keep tclsh.

 package require Tk 8.4

The simple line above in a Tcl script, even if run by tclsh, will immediately make all Tk functionality available throughout the rest of the program. A little (just a little) more about that is discussed in Using Tk as a loadable package.

LV Question - is this true on Windows? Or are there two different tclsh's on Windows ... one with and one without graphical support? I seem to recall that there was something strange with stdout and stdin on Windows... that using tclsh had support for redirected stdin and stdout but using wish on Windows didn't have those, perhaps because of the console that is present on that platform?

LV: I notice that DGP writes on comp.lang.tcl that there are subtle differences, at least on Windows, between the tclsh/package require and the wish. He didn't go into details though.

Another user mentioned that they use:

 package require Tk [info tclversion]

so as to ensure that they get the Tk that matches the Tcl being used.

Someone also added that: "At a MS-DOS prompt I can say...

 tclsh myscript.tcl >output.txt

... to capture the output (of practically unlimited size). Using wish for this kind of stuff might be possible but would be more involved IMO."

The information was confirmed by a notorious Tcl expert, who also said that "Tkcon would require an exec at the beginning of that command"

But it still puzzles me:

 wm withdraw .
 puts "hi, Mom"
 exit

The script above can be run by wish and produce the same result as tclsh.

  wish myscript.tcl >output.txt

in a MS-DOS prompt produces just the same result as...

 tclsh myscript.tcl >output.txt

I also ran wish myscript.tcl >output.txt from Tkcon, without the exec command, and had exactly the same result (shrug).

So, my conclusions so far are:

if I use wish instead of tclsh, I have to use wm withdraw . if I don't want any windows, and exit because wish won't exit automatically like tclsh;
wish uses up more resources than tclsh, and that is often not good;
if there is no $DISPLAY environment variable available, wish refuses to initialize, but that is hard-coded and I wonder if it could be changed. [ CL notes that "Image manipulation without Tk", which now appears just confusing, has fragments of an explanation that bears on this topic.]

Note that I don't really want to get rid of tclsh. It is all just for the sake of getting a better grasp of the differences between the two programs.

SLB From an MS-DOS prompt try running

  wish myscript.tcl

i.e. with no redirection. The output will be lost. Conversely, if you setup file extensions so you can run Tcl scripts from Windows Explorer via tclsh, you will get an MS-DOS Window.

Matthias Hoffmann: Even wish xyz.tcl>con does not work, while type xyz.dat>con does. Perhaps the reason is that win32-GUI-Programs are not automatically have the standard-channels (STDOUT, STDERR, STDIN) availabe, I think - so I wonder why wish xyz.tcl>file work at all...

RLH You will not get the MS-DOS Window if you require the Tk package in your Tcl script. Even after reading all of this I come away with "we only really need tclsh now.". Am I missing something?

  package require Tk 8.4

SLB Hmm, not what I see. Let's be specific. I'm running ActiveTcl 8.4.5 on Windows 2000. If I use the Run option from the start menu to launch tclsh84 I get a MS-DOS window. I can use

  package require Tk 8.4

and the MS-DOS window is still there. I try the command

  console show

I see:

  invalid command name "console"

So the wish console is not available from tclsh. That's one difference between wish and tclsh

Matthias Hoffmann: The DOS-Window is the console for tclsh-programs, so another console makes no sense ;-) The console internally is a text-widget, I think, implemented an initialized by wish.exe, so it is unavail from tclsh. Perhaps it would better be independent?

If I now take a simple Tcl script such as:

  package require Tk
  button .b
  pack .b

save it in a file and double click on the file from Windows Explorer, then the wish top level window appears with no DOS window. Perhaps this is what you meant?

But now, I go to Windows Explorer's Tools menu, select Folder Options and then choose the File Types tab. I locate the file type Tcl and press Advanced to see its actions. I choose action 'open' and press Edit... This reveals that 'open' uses wish84. Change it to tclsh84, OK all the dialogs and try running the script again. I now see DOS prompt.

Matthias Hoffmann: if a program is once started with tclsh, the console, that is the text-mode DOS-window, remains open, even after package requiring Tk. This is normal behaviour and is the same with rexx, perl, bat/cmd - with any textbased program. I think there's a flag somewhere in the exe-header and/or a compile-time-decision if the window of a text-based-program is visible or not, but I don't remember this exactly...

DKF: Apparently, the auto_path is different between tclsh and wish in MacOS X. I don't know the details, but what I've heard so far involves the phrase "frighteningly ugly platform details" AFAICT...

Lars H: Different distributions, perhaps? I've installed the TclTkAqua-8.4.5 batteries included distro, but now I notice that /usr/bin/tclsh is still some 8.4.4. Apart from two dirs that seem directly derived from the path of the executables, the only difference I get is that some directories of BI things are missing from the tclsh auto_path.

Otherwise, what might qualify as "frighteningly ugly platform details" to people is perhaps rather the situation with env(PATH). In OSX, starting applications does generally not make use of any shell, so if you only set up the environment in a unix shell initialisation file then it hasn't been set up at all for applications not started from a command line. See [L1 ] [L2 ] [L3 ]

Category Internals	Category Platform Issues