Tcl Source Code

View Ticket
Login
Ticket UUID: 920667
Title: Correct utf handling of dirty lib path
Type: Bug Version: None
Submitter: hobbs Created on: 2004-03-21 22:04:03
Subsystem: 37. File System Assigned To: hobbs
Priority: 7 High Severity:
Status: Closed Last Modified: 2004-04-08 05:23:30
Resolution: Fixed Closed By: hobbs
    Closed on: 2004-04-07 22:23:30
Description:
It turns out that the tricks for all the special "dirty
utf" handling at startup between pre-init of encodings
and post-init that mangles the executable name and
library path isn't correct (at least on Win NT-based
platforms).  The following patch addresses that issue.
 It doesn't change behavior on unix (should it? maybe),
but it does for Windows.  Win9x needs testing to see if
this solution is correct.

Some random extra bits from emails to others:
----
Tcl starts up assuming everything in ascii, and
switches to unicode when TclWinSetInterfaces is called.
 That is:

tclMain.c:Tcl_Main
tclEncoding.c:Tcl_FindExecutable
tclEncoding.c:TclFindEncodings
  (TclpFindExecutable and TclpInitLibraryPath are
called first)
tclEncoding.c:TclpSetInitialEncodings
tclEncoding.c:TclWinSetInterfaces

The problem is that by this time, through the other
calls, we have established the nameofexecutable using
ascii functions, as well as init'ed our library path
with them.  That makes later calls to load stuff not
correct.
----

Earlier analysis by Andreas:

Urks. I have to start from the beginning. Because we
have two different paths to look at, and what I found
out so far applies to only one.

(A)file mkdir a\u6211b\u00aacJap. path.
(B)file mkdir ab\u00aacHigh-bit path.

All the results I talked about previously were for path
(B).

So, lets try again.

Created path for (A) and (B). Copied the all basekits
into both paths. Also copied the bin/lib part of a TDK
installation [*] into both. Also created a regular path
'abc' --> (C), and copied everything into it.

[*] IOW tclsh/wish with all relevant libraries and tcl
libraries. That becomes important later.

This is for Win 2000.


Results:
~~~~~~~~
Executable(A)(B)(C)
-------------------------
(1)bin/tclshFAIL/1OKOK
(2)bin/wishFAIL/1OKOK
-------------------------
(3)base-tclFAIL/2OKOK
(4)base-tkFAIL/2FAIL/3OK
-------------------------

Error text  Function, if known
-------------------------------------------------
-------------------
F/1: "App. init failed: Can't find usable 'init.tcl'." (x)
F/2: "App. init failed: file open failed"(Tcl_Init)
F/3: ""(Tcl_CreateConsoleWindow)

The interesting thing is that the _regular_ tclsh fails
for the japanese path as well. To me this means that
the regular initialization is hosed as well.

Here is the full message I get for FAIL/1, with the
paths looked at placed on separate lines for clarity.
And there it tries the jap. directory the path names
are severely mangled. Not finding the init.tcl although
it is present (See [*] above).

application-specific initialization failed: Can't find
a usable init.tcl in the following directories:

    C:/trans/a?eab-?c/lib/tcl8.4
    C:/trans/a?b?c/lib/tcl8.4
    C:/trans/lib/tcl8.4
    C:/trans/a?b?c/library
    C:/trans/library
    C:/trans/tcl8.4.6/library
    C:/tcl8.4.6/library

I am leaving this setup in my file system for
inspection when you are back.

From the initial look it seems as if we have three
different bugs here, except that it not yet clear if
FAIL/2 is a different way for FAIL/1 to express itself,
and FAIL/3 might be a followup error to FAIL/2.
User Comments: hobbs added on 2004-04-08 05:23:30:
Logged In: YES 
user_id=72656

Patched post-8.4.6 and post-8.5a1.

vincentdarley added on 2004-03-30 16:35:14:
Logged In: YES 
user_id=32170

This isn't particularly in an area of the fs that I'm too
familiar with, but the patch does appear to work for me, and
looks relatively clean.

hobbs added on 2004-03-30 03:07:18:

File Deleted - 80871: 



File Added - 81806: libpathutf.patch

hobbs added on 2004-03-30 03:07:16:
Logged In: YES 
user_id=72656

Updated patch against 8.4-branch on 2004-03-29 that was
commited.  Now testing wide and with starpacks to ensure
major happiness, then upport to head.

dgp added on 2004-03-24 01:26:50:
Logged In: YES 
user_id=80530


Without actually trying this on
the troublesome platform, it
looks sound to me.  Even suggests
some possibly parallel changes 
to unix to consider separately.

A commit of this patch (and a
suitable version for the HEAD)
is fine with me.

dgp added on 2004-03-24 00:23:15:
Logged In: YES 
user_id=80530

first sanity check.  patch applies
clean to core-8-4-branch and
compiles and tests on my unix
platforms.

vincentdarley added on 2004-03-22 19:30:32:
Logged In: YES 
user_id=32170

Reassigning to init-library-autoload category.

hobbs added on 2004-03-22 05:04:04:

File Added - 80871: libpathutf.patch

Attachments: