Menu

#1537 unixInit-2.8 failure

obsolete: 8.4a3
closed-fixed
5
2001-07-02
2001-07-02
Don Porter
No

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

Discussion

  • Don Porter

    Don Porter - 2001-07-02

    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.

     
  • Don Porter

    Don Porter - 2001-07-02

    Bug fix.

     
  • Don Porter

    Don Porter - 2001-07-02
    • status: open --> closed-fixed
     
  • Don Porter

    Don Porter - 2001-07-02

    Logged In: YES
    user_id=80530

    Commited patch to fix bug.