Tcl Source Code

Ever since the 2001-06-18 commit to test/unixInit.test,
I've seen failures of test unixInit-2.8 when testing
from the development directory:

==== unixInit-2.8 TclpInitLibraryPath: all absolute
pathtype FAILED
==== Contents of test case:

    file delete -force /tmp/sparkly
    file delete -force /tmp/library
    file mkdir /tmp/sparkly
    file copy $::tcltest::tcltest /tmp/sparkly/tcltest

    file mkdir /tmp/library/tcl[info tclversion]
    close [open /tmp/library/tcl[info
tclversion]/init.tcl w]

    set allAbsolute 1
    foreach dir [getlibpath /tmp/sparkly/tcltest] {
        set allAbsolute [expr {$allAbsolute  && [string
equal absolute [file pathtype $dir]]}]
    }
    file delete -force /tmp/sparkly
    file delete -force /tmp/library
    set allAbsolute

---- Result was:
Path = /tmp/sparkly/tcltest
application-specific initialization failed: Can't find
a usable init.tcl in the following directories: 
    /usr/local/lib/tcl8.4 /tmp/lib/tcl8.4 /lib/tcl8.4
/lib/tcl8.4/library /library /tcl8.4a3/library
/usr/local/lib/tcl8.4



This probably means that Tcl wasn't installed properly.

---- Result should have been (exact matching):
1
---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
==== unixInit-2.8 FAILED

Logged In: YES 
user_id=80530

Commited patch to fix bug.

File Added - 8016: init.patch

Logged In: YES 
user_id=80530


The changes to unixInit-2.8 didn't fully account for
the different layout of Tcl's installed directories and
Tcl's source distribution directories.  That needs 
correcting.

Beyond that, though, making this test fail was actually
quite fortunate. Looking into why it failed caused me to
look at the search path being generated by
TclpInitLibraryPath().

It is just completely wrong, and has been for a long time.
The same completely wrong code also is in win/tclWinInit.c.

The pathv array of path components is being overwritten
and reused several times to construct the directory names
to be added to the library path.  Unfortunately the 
pathv array is not reset between each use, but the code
assumes it has been.  So, instead of constructing several
directory names relative to the path to the executable,
the first is constructed, the second is constructed relative
to the mangled path left by constructing the first, the
third relative to the magled path left by the second, etc.

The patch corrects all these problems.