Differences include: * [event loop] * various memory usage patterns [[?]] * [GUI] service Under DOS, 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''; * 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 [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 [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 a 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 a 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 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 DOS window. I can use package require Tk 8.4 and the 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'' f��¼r 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 [http://developer.apple.com/qa/qa2001/qa1255.html] [http://developer.apple.com/qa/qa2001/qa1067.html] [http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Concepts/EnvironmentVars.html] ---- [Category Internals]