> -----Original Message-----
> > Sorry, I haven't been following this thread.
> >
> > You can't have any idea where the tclsh.exe lives,
> > unless it's in you're PATH or (on Windows) in the
> > registry. You can't even know the name (is it
> > tclsh.exe or tclsh83.exe?), maybe a global variable
> > or some sort of config file for your script can
> > help with that.
>
> What if there is no tclsh.exe file at all? I thought
> the point of stubs was to remove all the "junk" you
> needed to know about a version of Tcl. Can we
> just call Tcl_FindExecutable(NULL), will that
> still set up the tcl library path properly?
You need to call Tcl_FindExecutable(<dll location>),
the NULL won't find the encoding directory but
should intitialize the basic encodings, and it
won't find the Tcl library on Unix. On Windows,
this can be automated in the DllMain() in tcl8x.dll,
but not on Unix (which will need an env variable
to figure it out). With stubs, you also need to
know where to pick up the tcl8x.dll and what number
the x is. An env variable (or registry on WinNT)
will solve this, just combine the two solutions.
TCL_SHLIB=/usr/local/lib/libtcl83.so
TCL_SHLIB=c:\\Program Files\\tcl\\bin\\tcl83.dll
This issue is also true for the Tcl Plugin, and
David Gravereaux had a working version that looked
at the registry on Windows, but this doesn't scale
to Unix. Each program could have it's own config
file instead, but I like it being common. If we
do this, then even tclsh can use it and be stubs
aware...
I'm going to send this to the TEA list as well...
-- Scott
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
