[Tcl-bugs] [ tcl-Bugs-920667 ] Correct utf

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

Bugs item #920667, was opened at 2004-03-21 22:04
Message generated for change (Comment added) made by vincentdarley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=920667&group_id=10894

>Category: 37. Init - Library - Autoload
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jeffrey Hobbs (hobbs)
>Assigned to: Don Porter (dgp)
>Summary: Correct utf 

Initial Comment:
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\u00aac		Jap. path.
(B)	file mkdir ab\u00aac			High-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/tclsh	FAIL/1	OK		OK
(2)	bin/wish	FAIL/1	OK		OK
	----------	------	------	---
(3)	base-tcl	FAIL/2	OK		OK
(4)	base-tk	FAIL/2	FAIL/3	OK
	----------	------	------	---

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.


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

>Comment By: Vince Darley (vincentdarley)
Date: 2004-03-22 12:30

Message:
Logged In: YES 
user_id=32170

Reassigning to init-library-autoload category.


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

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