$::tcl_interactive , a variable provided by tclsh and wish, is a boolean value that indicates whether the interpreter is in interactive mode.
If the value of $::tcl_interactive is true, the interpreter operates in interactive mode. The behaviour of the interpreter can be toggled between interactive and non-interactve mode by changing the value of $::tcl_interactive. See tclsh for a list of the differences between interactive and non-interactive mode.
Ro: You can shorten commands in interactive mode, e.g.: "inf" for "info".
RS 2004-03-24: Yup - and this is especially delightful on a PocketPC where less stylus-tapping is better. If the abbreviation is unambiguous, like ll for llength, it saves time and screen space; if it is ambiguous (e.g. 'l'), it is another introspection helper - the educational error message shows you the possible completions, just as info commands l* would have done.
% l ambiguous command name "l": label labelframe lappend lindex linsert list listbox llength load loadvfs lower lrange lreplace lsearch lset lsort % ll wrong # args: should be "llength list"
Just make sure that the interactive command is tried at global level (0), so that unknown (which provides abbreviation mode) finds itself at level 1.
If tclsh runs a script given on the command line, $::tcl_interactive is set to false, but adding the line
set ::tcl_interactive 1
gives you the described benefits, so I added that to iFile 1.1.
DGP: Note this feature is new in Tcl 8.4. Note also that the intended user of this feature is Tcl's test suite. Use with care.
JMN 2008: This variable seems to be undefined in new threads created using the Thread package. I suspect this is a bug, as other variables such as $::tcl_patchLevel do exist in new threads. On loading a module into another thread, which uses $::tcl_patchLevel to change its logging behaviour slightly, I get the error:
can't read "::tcl_interactive": no such variable
TomT - 2017-01-05 01:43:11
It turns out that MS windows figures out if a program is interactive or not. If that test says it is interactive a window is provided to "interact" in. From what I can tell tclsh always comes out interactive in this test while wish does not. On the other hand, on MS windows pipes work in tclsh but not in wish. Net result seems to be, if you want pipes you need to start in tclsh and "package require Tk". Down side is that pesky useless window. Or am I missing something?
bll 2017-1-4 No, I don't think you are missing anything. For my application, I start it with wish (so I can have an icon and no pesky window), then I restart the application with tclsh so that I can use stdout. Very annoying.
TomT On MS window-10 when you hover over the taskbar icon you see that pesky window (in my case the icon is in the middle of that display, but not if I click on it). I wonder if tclsh could "really" not do what ever MS thinks makes it interactive unless it really is. My application is windows intensive but I also need the pipes so I start tclsh and then package require into Tk. Only I/O it does is a source to bring in the major block of code.
Is there a package one can load from wish to do this little trick? If not, there should be.
bll 2017-1-5 The only way I found is as below. Start your program with wish, then do:
package require Tk
package require platform
if { [regexp -nocase {^win} [platform::generic]] } {
# change regexp as required to make sure it matches your wish executable
if { [regexp {wish\d*\.exe} [info nameofexecutable]] } {
# specify the full path to tclsh or have it in your path
exec tclsh [info script] &
exit
}
}This allowed me to have the proper icon for my program, no pesky window, and normal pipes and stdout (and unfortunately a longer startup time). I want to add some command line options and create a patch for wish that will change how stdout works so I don't have to do this, but it may be a while before I get around to it.
TomT 2017-01-05 Here is what I came up with to do the same thing:
set ex [info nameofex]
if {[string match -nocase {*wish*} [file tail $ex]] &&\
$tcl_platform(platform) == {windows} &&\
! [string match -nocase [file extension $argv0] {.exe}] &&\
[set target [auto_execok tclsh]] != {}} {
exec $target $trueFr {*}$argv &
exit 0
}
source $trueFr
Here "trueFr" is the main body of the script I want to run. The test of argv0 excludes the case of the process being wrapped.
I still haven't been able to get MS windows to put my icon in the task bar. If you have, may I ask how?
bll 2017-1-5 Create a .ico file as usual, and:
wm iconbitmap . -default [file join C:/my-path bdj_icon.ico]
TomT 2017-01-09
Ah... perfect, problem was an incorrectly built *.ico file. All good now.