[Tcl-bugs] [ tcl-Bugs-579617 ] encodings can't be found

[<no...@so...>]

Bugs item #579617, was opened at 2002-07-10 06:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=579617&group_id=10894

Category: 36. Init - Library - Autoload
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean-Claude Wippler (jcw)
Assigned to: Don Porter (dgp)
Summary: encodings can't be found

Initial Comment:
Context: tclkit, which uses the std unix/tclAppInit.c, 
but overrides Tcl_AppInit (using TCL_LOCAL_APPINIT).

Basic logic, from my (fragmentary) understanding:
   std main starts
   does a Tcl_FindExecutable
   launches custom tclkit_AppInit
   loads a few static extensions
   sets up a preinit script [1]
   call Tcl_Init

The tclkit init code is relatively small, it's at:
   http://www.equi4.com/metakit/viewcvs.cgi/*checkout*/
tclkit/src/kitInit.c?rev=1.9

[1] The preinit script is the one that loads TclVFS 
which provides scripting access to the VFS C layer in 
the Tcl core.

----
Observed behavior: on Unix/Linux, "encoding system" 
returns "identity".  UNLESS the executable is run on the 
build machine - THEN it find the installed encodings due 
to the fact that it remembers (!) a static absolute path 
of where the tcl8.4/ area is installed.
----

The special situation in Tclkit is that it stores 
encoding files inside a VFS, and that it uses a bit of 
Tcl scripting to set things up *before* encoding files 
can be accessed.

Therefore the first call to Tcl_FindExecutable will not 
be able to get encodings right - nor even a call to 
Tcl_SetDefaultEncodingDir - because at least one interp 
has to run scripts before VFS is ready.

For that reason, Tclkit includes a "librarypath" command 
coded in C, written by Vince Darley, which gets called 
from Tcl as soon as the VFS mount is in place.  The code 
for this is a few dozen lines, see:
   http://www.equi4.com/metakit/viewcvs.cgi/*checkout*/
tclkit/src/pwb.c?rev=1.6

The essential calls there are:
        TclSetLibraryPath(Tcl_NewListObj(1,&path));
        TclpSetInitialEncodings();
        Tcl_FindExecutable(Tcl_GetVar(interp, "argv0", 
TCL_GLOBAL_ONLY));

What happens, is that Tcl_FindeExecutable gets called a 
second time - not sure why this is needed.

Any help on this issue would be greatly appreciated - 
I'm sort of way beyond my understanding of how things 
work or could be made to work...

Perhaps unrelated, but worth noting, is that tclkit also 
has trouble when run through a symlink (this is 
definitely of secondary imortance to me for now).


----------------------------------------------------------------------

>Comment By: Joe English (jenglish)
Date: 2002-07-10 17:45

Message:
Logged In: YES 
user_id=68433

Part of the problem is that Tcl_FindExecutable() does a
whole lot more than just finding the executable.  It also
(indirectly) initializes all subsystems, sets the library
path, and sets the encoding path.

This presents something of a catch-22 for TclKit and similar
programs: they need to find the executable to mount the VFS
to set the library and encoding paths, but by the time
Tcl_FindExecutable() returns these have already been set
(after crawling up the filesystem looking for something that
either isn't there or shouldn't be used!)

We can't change Tcl_FindExecutable() (too many custom Tcl
shells rely on this behaviour), but having a different
routine that _only_ finds the executable would be helpful. 
This wouldn't even need to go in the stubs table -- it, like
Tcl_Main, is only needed for application initialization. 

----------------------------------------------------------------------

Comment By: Jean-Claude Wippler (jcw)
Date: 2002-07-10 06:26

Message:
Logged In: YES 
user_id=1983

Whoops, bad title description: the encodings do get loaded 
fine, "encoding names" gives the subset I expect.  It's just 
that the init is not happening, "encoding system" ends up 
being "identity" on startup.

Win32 works fine, different code path.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=579617&group_id=10894