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:
- default_path.patch [download] added by marc_culler on 2025-06-09 02:55:25. [details]