Calling helper scripts on Windows

[Kevin Walzer]

I'm trying to take a Unix-based Tcl/Tk application that I'm working on
and design it in a more platform-neutral fashion (meaning: will run on
Windows).

Short description: the app is divided into a couple of components: the
main (GUI) part, and a couple of helper scripts that implement
under-the-hood functionality. I call the helper scripts via "open |" and
fileevent. The scripts themselves are set as executable and are executed
by the system-installed tclsh (#!/usr/bin/tclsh). I developed this
design to keep the GUI from locking up while the helper processes ran.

Because Windows doesn't have tclsh installed, what's the best way to
achieve the functionality I'm looking for? The only thing I can think of
is to wrap each script separately. I read about Winserv at the wiki, but
that seems too complex for my needs.

Any other ideas?

[suchenwi]

It's a matter of a few minutes to install e.g. ActiveTcl on Windows,
including associating the ".tcl" extension.

[Kevin Walzer]

suchenwi wrote:
> It's a matter of a few minutes to install e.g. ActiveTcl on Windows,
> including associating the ".tcl" extension.
>

I don't want my end users to have to do that. I want the application to
run as a self-contained standalone.

[Bryan Oakley]

Well, if your app is running there's obviously a tcl interpreter
available, right? Just re-exec your own executable. Or is there a reason
that won't work?

The other option is to use threads and run your helper procs in a thread
of the existing executable rather than as separate processes.

[suchenwi]

You could put all your helper scripts into the same wrapped executable,
and call another instance of it, qualified over the command line. For
simplicity's sake, let's use [exec] for this sketch - a three-process
solution for printing "hello, world!" :-)

proc main argv {
switch -- [lindex $argv 0] {
this {puts hello; exit}
that {puts world; exit}
{} {# no arguments, main instance
puts "[exec [info na] $::argv0 this], [exec [info na] $::argv0
that]!"
}
}
}
main $argv
----
For testing this as a script in normal tclsh, I had to add the $::argv0
script name. In a wrapped executable, you may not need it - just [puts
$argv] to find out how it is called.

[Roy Terry]

"Kevin Walzer" <s...@wordtech-software.com> wrote in message
news:3d1ec$43cfb5a5$4275d90a$14...@FUSE.NET...

You could just grab a copy of
freewraptclsh (rename it anything you
want)
http://sourceforge.net/project/showfiles.php?group_id=15218

It is a single file equivalent to a full tcl install
for tclsh.exe
Put the freewrap thingy into your wrap and
unpack it at install. Done.

>
> Any other ideas?
>

[Kevin Walzer]

Bryan Oakley wrote:

>>
>
> Well, if your app is running there's obviously a tcl interpreter
> available, right? Just re-exec your own executable. Or is there a reason
> that won't work?

Hmmm. That's so blindingly obvious I didn't think of it.

Using code like this:

set exectool [info nameofexecutable]
set helpertool [file join [file dirname [info script] ] footool.tcl]

works fine on the Mac, and I'm sure it would work equally well on Windows.

An interpreter recursively calling itself and opening a pipe to
itself...cool.

Thanks!