Ticket UUID: | 43c94f95988f3057fcabbd2a4b81c6e8ff9909a6 | |||
Title: | Tcl will not start properly if there is an init.tcl file in the current dir | |||
Type: | Bug | Version: | 9.0 | |
Submitter: | stu | Created on: | 2024-11-12 04:44:21 | |
Subsystem: | 38. Init - Library - Autoload | Assigned To: | sebres | |
Priority: | 5 Medium | Severity: | Important | |
Status: | Closed | Last Modified: | 2024-11-14 11:49:42 | |
Resolution: | Fixed | Closed By: | jan.nijtmans | |
Closed on: | 2024-11-14 11:49:42 | |||
Description: |
This on my system. Your auto_paths may vary. $ echo 'puts $::auto_path' | tclsh8.6 /usr/local/lib/tcl/tcl8.6 /usr/local/lib/tcl $ echo 'puts $::auto_path' | tclsh9.0 /usr/local/lib/tcl/tcl9.0 /usr/local/lib/tcl $ echo '' > init.tcl $ echo 'puts $::auto_path' | tclsh8.6 /usr/local/lib/tcl/tcl8.6 /usr/local/lib/tcl $ echo 'puts $::auto_path' | tclsh9.0 can't read "::auto_path": no such variable Wish provides a different error message for the same problem: $ wish9.0 application-specific initialization failed: invalid command name "tcl_findLibrary" And for fun: $ echo 'puts "I like fish!"' > init.tcl $ echo 'puts $::auto_path' | tclsh9.0 I like fish! can't read "::auto_path": no such variable | |||
User Comments: |
jan.nijtmans added on 2024-11-14 11:49:42:
@sebres, if you like to "merge --cherrypick" this fix to the core-8-5-branch, just go ahead. (I'm not interested in this branch any more) jan.nijtmans added on 2024-11-14 09:35:44: Problem in testcase fixed [837f2fa878f7d776|here]. Unfortunately, it caused a broken macOS build on Github actions. This is exactly why I am advocating fixing bugs firt on trunk, and only cherrypick to lower branches after trunk builds are successful. jan.nijtmans added on 2024-11-13 21:45:52: Well, Sergey finished the work, updating all branches with a fix. Even 8.5/8.6, because the same could happen there if $pkgPath contains {} as list element. Thanks! stu added on 2024-11-13 16:19:04: You're pretty quick, Jan! Yes it is only with a --disable-zipfs build. I just did some digging and ran some tests after getting the hint from Harald and arrived at the thought that the path might be "". Didn't investigate further as I came here to add the note about --disable-zipfs. The fix you provided looks good but I don't know enough about that area of the code to evaluate if it's the best/right fix. Probably is. :) jan.nijtmans added on 2024-11-13 15:50:44: My guess: You used a --disable-zipfs build (which you didn't mention in the bug-report). In that case, "::tcl::zipfs::tcl_library_init", which should return the tcl_library directory in the zipfs might return the empty string. If $tcl_library is the empty string, then [file join $tcl_library init.tcl] (tclInterp.c:449) will point to init.tcl in the current directory. If my guess is right, [465d4546e2|this] should solve the problem. jan.nijtmans added on 2024-11-13 15:21:10: Trying to reproduce it: $ echo '' > init.tcl That looks fine to me. Did you set any environment variables, like TCL_LIBRARY or TCLPKGPATH? What platform? anonymous (claiming to be oehhar) added on 2024-11-13 14:46:25: Stuart, thank you for the example. I fear, it works as expected. The default init.tcl is in library\init.tcl You may look into generic\tclInterp.c, function "Tcl_Init" how an alternate init script may be specified. I also see this as a security hole. Thank you, Harald |