Directory search order on Windows
lie...@us.ibm.com
I found a section of the ActiveTcl documentation which says the exec
command uses this search order:
The directory from which the Tcl executable was loaded.
The current directory.
The Windows 95 system directory.
The Windows 95 home directory.
The directories listed in the path.
Is this the search order that is used by the source command also?
If this is so, can anyone explain to this newbie why TCL installations
typically put the .TCL file in several different directories and don't
modify path? It seems pretty restrictive to always have to start from the
directory where the source files are.
Am I missing something?
David Liebtag
IBM APL Products and Services
Bryan Oakley
news:9ja2ti$ivu$1...@stlnews.stl.ibm.com...
> What search order does TCL use on Windows?
>
> I found a section of the ActiveTcl documentation which says the exec
> command uses this search order:
>
> The directory from which the Tcl executable was loaded.
> The current directory.
> The Windows 95 system directory.
> The Windows 95 home directory.
> The directories listed in the path.
>
> Is this the search order that is used by the source command also?
No. Source doesn't search anywhere. It takes the path given to it, relative
to the current directory if it's not absolute.
>
> If this is so, can anyone explain to this newbie why TCL installations
> typically put the .TCL file in several different directories and don't
> modify path? It seems pretty restrictive to always have to start from the
> directory where the source files are.
Hmmm. I'm not sure what you're saying there. Any well behaved Tcl program
should be able to be started from anywhere and should not use the source
command except with absolute filenames. That's not to say there aren't
programs that do that, but that's typically not how things work.
Read up on the package command to see how things are supposed to work.
Ideally, an application will have all of it's source in one file, and/or do
something like "package require <whatever>" to load in external code.
Jeff Hobbs
...
> > If this is so, can anyone explain to this newbie why TCL installations
> > typically put the .TCL file in several different directories and don't
> > modify path? It seems pretty restrictive to always have to start from the
> > directory where the source files are.
I didn't see the original to this, only Bryan's response.
Anyway, the way that Windows knows to launch wish when you
double-click on the .tcl file is by the file association
made in the registry.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
lie...@us.ibm.com
I am adding an interface to TCL from my product, which is itself a
programming language. Inside my interface I call TCL_CreateInterp and
then Tcl_Init. Tcl_Init fails with an error message saying it can't find
init.tcl in the following directories. The directory list is empty. If I
copy init.tcl into the current directory, Tcl_Init works.
The Tcl error message seems to imply that there is someway to supply a
search order. I can not find any mention of this in the installation or
language documentation.
I need to find a way to specify a search order because I can not require
my customers to always run from a particular directory.
So again,,,,
Does anyone know what search order TCL uses for .TCL files and how I can
change it?
Thanks in advance.
Don Porter
> I am adding an interface to TCL from my product, which is itself a
> programming language. Inside my interface I call TCL_CreateInterp and
> then Tcl_Init. Tcl_Init fails with an error message saying it can't find
> init.tcl in the following directories. The directory list is empty. If I
> copy init.tcl into the current directory, Tcl_Init works.
There are a number of things you can do, depending on what particular
things you need Tcl to do for you, and what version of Tcl you have.
The simplest fix, if it works for you, is to leave out the Tcl_Init()
call entirely. The purpose of Tcl_Init() is to define some of Tcl's
builtin commands by finding and evaluating the init.tcl file If you don't
need the commands documented in library(n) -- mostly support for Tcl's
package loading and auto-loader -- then omit the Tcl_Init() call.
But if you need to be able to load Tcl packages (notably Tk) in the
interp, or you need something else from library(n), then you need to be
able to find and evaluate the init.tcl file, or the equivalent.
You say that the search path reported in the error message is empty.
That symptom usually means you left out a call to
Tcl_FindExecutable() before the call to Tcl_Init(). Add a call to
Tcl_FindExecutable(argv[0]);
in your main(). That should provide a search path of directories
relative to the installed location of your executable, and you will
need to see that init.tcl, and the rest of the files in the library/
directory of the Tcl source distribution, gets installed in one
of those directories. In a proper Tcl installation, that will
already be the case.
You might prefer exercising more control over exactly where your
application will find init.tcl. You can do that by setting the
global Tcl variable tcl_library before the call to Tcl_Init():
interp = Tcl_CreateInterp();
Tcl_SetVar(interp, "tcl_library", DIRECTORY, TCL_GLOBAL_ONLY);
Tcl_Init(interp);
where DIRECTORY is a string holding the name of the directory containing
init.tcl. When $::tcl_library is already set before the call to Tcl_Init(),
it will look there and only there for init.tcl. [*]
Or, you might prefer not having to have an init.tcl file at all. That
can also be accomplished, if your Tcl is recent enough. Since at
least Tcl 8.0.3 (maybe longer), all Tcl_Init(interp) *really* does is
evaluate the command [tclInit] in interp. If no such command is
defined, then Tcl_Init() defines one that does the search for init.tcl.
But you can define your own [tclInit] before calling Tcl_Init() and have
it do whatever you want.
interp = Tcl_CreateInterp();
Tcl_Eval(interp,
"proc tclInit {} {rename tclInit {}\n"
" # do my initialization stuff\n"
" # provide my own [unknown], etc.\n"
"}\n");
Tcl_Init(interp);
Sorry this has been so long, but Tcl initialization has lots of useful,
incompletely documented hooks when you are embedding it in a C program.
Future Tcl releases may have even more (see TclSetPreInitScript).
[*] Note that defining ::tcl_library is a compile time solution. There
is an analogous runtime solution available to end users. They can set
the environment variable TCL_LIBRARY to the directory containing init.tcl.
This should be used only as a last resort workaround.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Joe English
> interp = Tcl_CreateInterp();
> Tcl_Eval(interp,
> "proc tclInit {} {rename tclInit {}\n"
> " # do my initialization stuff\n"
> " # provide my own [unknown], etc.\n"
> "}\n");
> Tcl_Init(interp);
but really meant to say:
static char initScript[] =
"proc tclInit {} {rename tclInit {}\n"
" # do my initialization stuff\n"
" # provide my own [unknown], etc.\n"
"}\n";
...
interp = Tcl_CreateInterp();
Tcl_Eval(interp, initScript);
Tcl_Init(interp);
--Joe English
(who has made the same mistake more times than he can count...)
lie...@us.ibm.com
Thanks for all the good information. I had discovered the TCL_LIBRARY
environment variable technique and am glad to know that's not the best
approach. I will try out your suggestions so I can figure out which one
is best for my situation.
Thanks again.
lie...@us.ibm.com
Well, I've read your letter more carefully and thought a bit more and come
to the conclusion it really doesn't solve my problem.
Your comments seem to assume that I am building a TCL application and my
installation procedure will have some control (or knowledge) of where the
TCL files are located. This is not correct.
I am enhancing an existing product by adding an interface to TCL. Our
product already has an installation procedure which has a directory
structure which we can not change. Furthermore, we do not plan on
shipping TCL with our product. The customer will do their own TCL install
either before or after installing our product. We have no control over
where the customer puts TCL.
Basically, from an arbitrary directory, we (on our customer's behalf) are
going to issue Tcl_CreateInterp, Tcl_Init, and Tk_Init. As far as I can
tell, the only way to make this work is to require that the customer set
the TCL_LIBRARY environment variable.
Thanks for your ideas though.
Don Porter
> Your comments seem to assume that I am building a TCL application and my
> installation procedure will have some control (or knowledge) of where the
> TCL files are located. This is not correct.
> I am enhancing an existing product by adding an interface to TCL. Our
> product already has an installation procedure which has a directory
> structure which we can not change. Furthermore, we do not plan on
> shipping TCL with our product. The customer will do their own TCL install
> either before or after installing our product. We have no control over
> where the customer puts TCL.
Well that narrows down the list of choices I offered before, but the
good news is that it leaves the simple solutions.
You are depending on the customer's existing Tcl installation. Either
it was installed right, or it wasn't.
If it was installed right, then it already includes an init.tcl file,
and as long as you call Tcl_FindExecutable() before you call
Tcl_Init(), it should be able to find it without further help from
you.
If it wasn't installed right, then your customer will have to fall
back on the "last resort" solution provided by Tcl: definition of
the TCL_LIBRARY environment variable to the directoriy containing
init.tcl.
lie...@us.ibm.com
Thanks Don.
David Liebtag
I followed your advice of calling Tcl_FindExecutable before calling Tcl_Init.
This worked like a charm on Windows.
Now I am testing my code on a Linux system and Tcl_Init is again unable to find
init.tcl. Like on Windows, my product is installed in one directory tree and
Tcl is installed in another. When Tcl_Init fails, it lists a variety of
directory names it has constructed, but none of them are correct. Here are the
details:
Tcl was installed in /usr/local/ActiveTcl. This directory contains the normal
Tcl subdirectory tree.
My product is installed in /home/lin2dev/Optimize/bin.
As you can see,
For some reason, Tcl_Init doesn't look in the cirrect directory which is:
/usr/loca/ActiveTcl/lib/tcl8.3
Instead, Tcl_Init constructs a variety of directory names. Most of the
constructed names use my product's directory tree. Here are the directories
Tcl_init says it searched:
/usr/local/ActiveTcl/lib
/home/lin2dev/Optimize/lib/tcl8.3
/home/lin2dev/lib/tcl8.3
/home/lin2dev/lib/tcl8.3/library
/home/lin2dev/library
/home/lin2dev/tcl/tcl8.3/library
/home/tcl8.3/library
/usr/local/ActiveTcl/lib
You mentioned in your previous post that my code would depending on the
Tcl installation being correct. Well, I used the shell script that I downloaded
directly off www.scriptics.com. Does this mean the shell script installed
Tcl incorrectly? Or, did I make a mistake somewhere? Can you help me
figure out the problem?
I'm sorry if this is a dumb newbie question, but I'm stuck since I have little
Unix knowledge.
Thanks in advance.
Jeffrey Hobbs
...
> For some reason, Tcl_Init doesn't look in the cirrect directory which is:
>
> /usr/loca/ActiveTcl/lib/tcl8.3
This was a bug found in the installer for 8.3.3.3 that we didn't
find until yesterday. If you would like, we can give you a new
install.tcl script that fixes this. The fix will also be in the
next release (a few weeks from now).