Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-3587096 ] win vista/7: "can't find init.tcl" when called via junction
|
From: SourceForge.net <no...@so...> - 2012-12-13 09:49:31
|
Bugs item #3587096, was opened at 2012-11-14 02:46 Message generated for change (Comment added) made by oehhar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3587096&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 37. File System Group: development: 8.6.0 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Harald Oehlmann (oehhar) Assigned to: Alexandre Ferrieux (ferrieux) Summary: win vista/7: "can't find init.tcl" when called via junction Initial Comment: Platform: win vista/win 7 Tcl Versions: 8.5.13, 8.6.0rc0 The following error message arises, if wish86.exe is called with a path component with a directory junction with no "Directory list" right This is the case for German Windows Vista when wish.exe is in the folder c:\programme (which is a juction to "c:\program files"). "Can't find a usable init.tcl in the following directories: C:/programme/tcl8.6/lib/tcl8.6 C:/programme/tcl8.6/lib/tcl8.6 C:/programme/lib/tcl8.6 C:/programme/tcl8.6/library C:/programme/library C:/programme/tcl8.6.0/library C:/tcl8.6.0/library" -------------------------------------------------------------------------------- Unfortunately, I am not able any more to test this, as I applied the hotfix which changes that: http://support.microsoft.com/kb/969986 I have not found any way to rewind that. ------------------------------------------------------------------------------- The following test does not show this error, but a similar one. The shown error message complains about a not found tk.tcl. Do the following steps (translated from german dialogs): - you have a tcl installation in a path, say c:\test\tcl860rc0 - open an administrator dos box - enter there: cd c:\test mklink /j tcl860rc0_junction tcl860rc0 - use the windows explorer, open the properties of the junctions, tab security: - Press the continue button to open the "Rights for tcl860rc0_junction tcl860rc0" dialog box - Select "Users" in the listbox "Graup and User names" - Select the "Deny" checkbox for "Show folder contents" The attached image shows the german version of the dialog - Press "Apply" - Ceate a batch file with the following contents: c:\test\tcl860rc0_junction\bin\wish86.exe <EOF> Adjust the name of the wish executable, if your name is different. - execute the batch file. It appears a message box with the following text: "Can't find a usable tk.tcl in the following directories: C:/test/tcl8.6.0/library/tk8.6 C:/test/tcl8.6.0/tcl8.6 C:/test/tcl860rc0_junction/lib/tk8.6 c:/test/lib/tk8.6 c:/test/tcl860rc0_junction/library" ------------------------------------------------------------------------ IMHO, one should introduce a "[file normalize ]" around the generation of the parentDir variable in Line 370 of tclInterp.c: The current code is: set parentDir [file dirname [file dirname [info nameofexecutable]]] to avoid this issue, one may use: set parentDir [file normalize [file dirname [file dirname [info nameofexecutable]]]] At least, this helps in my scripts to get rid of directory junctions related issues. A sample session with the "c:\Programme" junction: C:\test>c:\Programme\tcl8.6\bin\tclsh86t.exe % info nameofexecutable c:/Programme/tcl8.6/bin/tclsh86t.exe % file normalize [info nameofexecutable] C:/Program Files/tcl8.6/bin/tclsh86t.exe --------------------------------------------------------------------- Unfortunately, in the upper test case, it fails. Example session: (the upper example, but with tclsh86t.exe in the batch file: c:\test\tcl860rc0_junction\bin\tclsh86t.exe C:\test>c:\test\tcl860rc0_junction\bin\tclsh86t.exe % info nameofexecutable c:/test/tcl860rc0_junction/bin/tclsh86t.exe % file normalize [info nameofexecutable] C:/test/tcl860rc0_junction//tclsh86t.exe Remark the double "//" - the path component "bin" disapeared. --------------------------------------------------------------------- Related core list thread: http://code.activestate.com/lists/tcl-core/12335/ ---------------------------------------------------------------------- Comment By: Harald Oehlmann (oehhar) Date: 2012-12-13 01:49 Message: The patch proposed in tcl bug # 3092089 solves the issue for me. See comment Date: 2012-12-13 01:47:16 PST Sender: oehhar for details. Thank you, Harald ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-11-15 04:57 Message: ferrieux is sometimes interested in, and always good at, solving puzzles. Can you make any sense out of these findings? Reproduce and solve them? The [file normalize] workaround is apparently available, but unattractive if it leaves the deeper problem unresolved and if it has the potential to upset matters on other platforms. ---------------------------------------------------------------------- Comment By: Harald Oehlmann (oehhar) Date: 2012-11-15 01:32 Message: To your question, which command fails: as there is no "error" part in the message, only file exists should say 0. I tried it with an initialized wish and a fragment from the script in tclInterp.c (from line 389): (bin) 1 % lappend dirs "C:/test2_junction/tcl860rc0/lib/tcl8.6" C:/test2_junction/tcl860rc0/lib/tcl8.6 (bin) 2 % set tcl_library [lindex $dirs end] C:/test2_junction/tcl860rc0/lib/tcl8.6 (bin) 3 % set tclfile [file join $tcl_library init.tcl] C:/test2_junction/tcl860rc0/lib/tcl8.6/init.tcl (bin) 4 % file exists $tclfile 1 (bin) 5 % source $tclfile (bin) 6 % set errorInfo can't read "::tcl_pkgPath": no such variable while executing "foreach Dir $::tcl_pkgPath { if {$Dir ni $::auto_path} { lappend ::auto_path $Dir } }" So, it is not reproducible by this method. ---------------------------------------------------------------------- Comment By: Twylite (twylite) Date: 2012-11-15 01:13 Message: Could this be related to bug 3545366? There have been a couple of past problems with file system link normalization. ---------------------------------------------------------------------- Comment By: Harald Oehlmann (oehhar) Date: 2012-11-15 01:05 Message: I can also easily demonstrate bug 3092089 with the setup of my last post. If a path passes by a junction, the next path component is set to the empty string if this component exists: To demonstrate, use the upper setup with c:\test2 and c:\test2_junction pointing to c:\test2 Start any wish and type: (bin) 2 % file normalize c:/test2_junction/tcl860rc0 C:/test2_junction/ (bin) 3 % file normalize c:/test2_junction/tcl860rc0/bin C:/test2_junction//bin This does not happen, if the path does not exist: (bin) 4 % file normalize c:/test2_junction/tcl860rc0/bin/junk C:/test2_junction//bin/junk ---------------------------------------------------------------------- Comment By: Harald Oehlmann (oehhar) Date: 2012-11-15 00:58 Message: I rethought why the bug did not appear with the demonstrator. It is due to the fact, that in my test folder, there is also the source distribution of tcl8.6.0 and this tcl8.6.0/library/init.tcl was used. Thus I made a new try in a new folder which succeeded: - cd \ . mkdir test2 cp test2\tcl860rc0 \test2 (syntax incorrect, used explorer) mklink /j test2_junction test2 - windows explorer: - properties of test2_junction - page security - Button "Change" (with Admin sign) Windw "Permissions for test2_junction" opens - click "any" in user name pane - Click the deny checkbox for "Show Folder" (well translation may also be "list folder") - ok ok - batch file with: c:\test2_junction\tcl860rc0\bin\wish86t.exe - start batch file. A box appears with: "Can't find a usable init.tcl in the following directories: C:/test2_junction/tcl860rc0/lib/tcl8.6 C:/test2_junction/tcl860rc0/lib/tcl8.6 C:/test2_junction/lib/tcl8.6 C:/test2_junction/tcl860rc0/library C:/test2_junction/library C:/test2_junction/tcl8.6.0/library c:/tcl8.6.0/library" ---------------------------------------------------------------------- Comment By: Twylite (twylite) Date: 2012-11-14 07:00 Message: I'm only following this conversation with half an ear, so please feel free to ignore this if it's not relevant: If anything in the Tcl startup or in the distribution libraries (including resource finding scripts in msgcat, clock, etc.) expects or relies on any path returned by tcl::pkgconfig to be valid, then that logic is utterly, completely and unfixably(*) broken on all Windows platforms. (*) There is a fix: remove any reliance on pkgconfig being right. pkgconfig should only ever be used to discover the build configuration of a shell (and its libraries) for the purposes of building another extension to work with that shell (under the explicit assumption that you're on the machine that build the shell [or an identical setup] and that you installed the shell to the location that you specified in the build scripts). Moreover if anything in the Tcl startup or in the distribution libraries attempts to use tcl::pkgconfig or an environment variable in preference to relative paths then there is a security hole that needs attention (a user could inject a script of their choice into an interp, even when filesystem access controls prevent that user from modifying the Tcl interp or libs). ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-11-14 06:20 Message: You're demonstrating serious failure of basic Tcl functions on a common platform. Letting it go isn't my first choice. Let's see if we can bring in some other Windows expertise before giving up. Asking mistachkin first, but feel free to pass around to other helpful candidates. ---------------------------------------------------------------------- Comment By: Harald Oehlmann (oehhar) Date: 2012-11-14 06:11 Message: I am sorry, I can not help any more. My system does not show the bug and I have no idea how to rewind the hotfix. I have made many tries here, some are documented and all are failing somewhere. I tried to build a version of tcl with symbols where the build fails. So I propose to put this bug asleap as nobody can help. Sorry, Harald ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-11-14 05:34 Message: Please drill down and determine why the code as written is failing. Is it [source]? Is it [file exists]? Let's drill all the way down to the real bug first, then layer on workarounds if we still have to. I'll be limited in what I can actually do here, since I do not use the vista platform myself to reproduce the report and test possible fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3587096&group_id=10894 |
