Tcl Library Source Code

View Ticket
Login
Ticket UUID: e5f3dfc055cfd4cbd2928ff964413749f321c88e
Title: tcllib 2.0 install fails with default Tcl build
Type: Bug Version: 2.0
Submitter: apnadkarni Created on: 2024-05-02 13:50:59
Subsystem: Installer Assigned To: marc_culler
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2025-06-10 01:38:50
Resolution: None Closed By: marc_culler
    Closed on: 2025-06-10 01:38:50
Description:
`tclsh installer.tcl` fails to install for a standard Tcl build. The issue is that the installer by default picks a path in Tcl's `auto_path`. The default Tcl build uses zipfs for its support scripts and the tcllib install fails when it tries to create a directory in //zipfs:/... (operation not supported).

Not a very big deal since the target path can be changed but it would be nice if worked out of the box by checking file system before picking a path.
User Comments: marc_culler (claiming to be Marc Culler) added on 2025-06-10 01:38:50:
I had to make a change because I foolishly thought that string match would
accept a regular expression for the pattern.  After that I tested on macOS,
Windows and Ubuntu.  The default paths were reasonable and the installations
worked.  So I merged the fix and am closing this ticket.

marc_culler (claiming to be Marc Culler) added on 2025-06-09 20:12:59:
Andreas gave me permission to push to this repository, so I pushed a fix
to this bug in branch bug-e5f3dfc055c.  The fix is based on the patch that
I attached earlier.

marc_culler (claiming to be Marc Culler) added on 2025-06-09 02:53:29:
Apparently I don't have permission to push to this repository.
I am attaching a patch which does what I suggested.  It looks to me
like it will work.

Ashok, can you give me write permission on this repository?  If so,
would you please?

Thanks.

marc_culler (claiming to be Marc Culler) added on 2025-06-09 02:10:33:
As mentioned on the Core list, the default path is also wrong on macOS.
However, on macOS the script uses ::tcl_pkgPath, but that has the same
value as auto_path on macOS and does not exist on Windows.

The script would work correctly on macOS if it used the first path on the
auto_path list, instead of the last.  On Windows the correct path is the
last one on the auto_path list, but the script does not use auto_path at
all.

The actual code is:

        if {[string match [info nameofexecutable]* [info library]]} {
            # Starkit
            set libdir [file join [file dirname [file dirname [info nameofexecutable]]] lib]
        } else {
            # Unwrapped.
            if {[catch {set libdir [lindex $::tcl_pkgPath end]}]} {
                set libdir [file dirname [info library]]
            }
        }

The catch statement succeeds on macOS, giving the wrong answer, and fails
on Windows causing the result of [info library] to be used.  On Windows
[info library] returns //zipfs:/lib/tcl/tcl_library.

The default values of auto_path on linux, windows and macOS (with a
framewor build) are as follows (where $PREFIX is the prefix on unix
and the value of INSTALLDIR on Windows)

linux: //zipfs:/lib/tcl/tcl_library //zipfs:/lib/tcl $PREFIX/lib

Windows: //zipfs:/lib/tcl/tcl_library //zipfs:/lib/tcl $PREFIX/lib

macOS: /Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts
 /Library/Frameworks/Tcl.framework/Versions/9.1/Resources /usr/local/lib
 $HOME/Library/Tcl /Library/Tcl $HOME/Library/Frameworks
 /Library/Frameworks /Library/Frameworks/Tk.framework/Versions

For macOS many of those paths would never contain a package, and are
unlikely to even exist.  But that is more of a Tcl issue than a
Tcllib issue.

I think that one solution (given the current state of things) would
be to use the first item in the auto_path which does not begin with
"//zipfs:" as the default installation path.  That is guaranteed to
be a place where Tcl will look, and it is likely to also be a writable
directory, at least in the case where one is running the installer as
root on a unix system.

Attachments: