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:
- libpathutf.patch [download] added by hobbs on 2004-03-30 03:07:17. [details]