From: SourceForge.net <no...@so...> - 2004-09-30 17:21:11
|
Bugs item #1018980, was opened at 2004-08-30 10:10 Message generated for change (Comment added) made by vincentdarley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1018980&group_id=10894 Category: 35. Pathname Management Group: development: 8.5a2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Daniel South (wildcard_25) Assigned to: Vince Darley (vincentdarley) Summary: winFCmd-16.12 failure on WinXP Initial Comment: Tcl: v8.5a2 HEAD at 30-08-04 OS: WinXPsp1 Built with makefile.vc using VC7 ==== winFCmd-16.12 Windows file normalization FAILED ==== Contents of test case: set expectedResult [file normalize ${d}:] set ::env(HOME) ${d}: cd set result [pwd]; # <- Must not crash if { [string equal $result $expectedResult] } { concat ok } else { list $result != $expectedResult } ---- Result was: D:/ != D:/src_tcl/win ---- Result should have been (exact matching): ok ==== winFCmd-16.12 FAILED This can be summed up with:- (bin) 1 % set pwd [pwd] C:/Program Files/Tcl/bin (bin) 2 % file normalize "c:\program files" C:/Program Files/Tcl/bin/program files I also get failures on the clock tests for ":UTC" and ":GMT" not found, but this is probably due to the normalization failure. Clock tests affected are:- 31.1, 31.2, 31.3, 32.1, 34.3, 34.4, 34.5, 34.7, 34.8, 34.10, 34.11, 34.19, 34.20, 34.21, 34.22, 34.23, 34.24, 34.25, 34.29, 34.30, 34.31, 37.1. If these aren't corrected when the file normalization is, I'll re-submit them as a seperate bug. ---------------------------------------------------------------------- >Comment By: Vince Darley (vincentdarley) Date: 2004-09-30 17:21 Message: Logged In: YES user_id=32170 All of this is now in CVS, so closing the bug. ---------------------------------------------------------------------- Comment By: Daniel South (wildcard_25) Date: 2004-09-29 01:40 Message: Logged In: YES user_id=596509 Yes, these tests pass for me. Yes, they were the comments I meant. My confusion started with 'cd', with no args, treating the HOME path as absolute and normalize not. The test was obviously meant to check that 'cd' changed to the HOME dir correctly, but the difference in path resolution was making it fail. After your patch, I ran the test again with puts output for the variables and everything was at root, so the test really wasn't testing anything useful, relative or absolute paths would have had the same result (turned out I had a CD-Disc in my drive triggering test 16.11 thus causing cwd to change to root, otherwise the test would have been testing relative resolution correctly). ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-09-28 17:21 Message: Logged In: YES user_id=32170 I've inserted your patch into my winFCmd.test, and all tests pass with CVS head. Is that your experience? ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-09-28 17:12 Message: Logged In: YES user_id=32170 I should add a caveat to my previous comment about case 3. While DOS does indeed seem to treat case 3 as D:/temp, in fact Tcl 8.0.x-8.3.x all treat it as 'D:/', and therefore Tcl 8.4 and 8.5 have followed that trend. (These are the comments you are probably referring to in tclPathObj.c). In principle this is perhaps a bug, but not one of major importance. I'll take a look at the patch -- thanks! ---------------------------------------------------------------------- Comment By: Daniel South (wildcard_25) Date: 2004-09-28 16:46 Message: Logged In: YES user_id=596509 Wrote a big speel on the behavior of 'cd' in XP DOS and then realized that, according to tclPathObj.c, 'C:' is treated as relative if the cwd is also on drive C and absolute if not. Now that 'cd' with no args (ie ~) follow the same rules, my confusion is starting to clear. :) attached patch for winFCmd.test bumped new 16.13 to 17.1 diffent section/description fixes clean up for 16.11 was changing to root instead of back to old pwd modified 16.13 for absolute HOME path added 16.13 to test relative HOME path ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-09-28 15:37 Message: Logged In: YES user_id=32170 Note: for me pwd is not D:/, and the test passes fine. In one of your examples below, case 3 should indeed be D:/temp, but that would require rather large changes in Tcl to support, because Tcl doesn't understand the notion of a per-drive pwd. Hence, for anything other than the current drive, ${X}:foo is interpreted as relative to the root of $X. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-09-28 08:45 Message: Logged In: YES user_id=32170 Can you perhaps provide 1 or 2 new tests which test what you believe needs testing and which fail for you? ---------------------------------------------------------------------- Comment By: Daniel South (wildcard_25) Date: 2004-09-28 05:11 Message: Logged In: YES user_id=596509 I shoud also mention that test now passes by default as pwd = D:/ (or drive root where tclsh is run from) on entering the test and so isn't really testing anything. Test passes if entry pwd is not root but this is now due to another error. values of test with non-root pwd. [pwd] = D:/src_tcl_orig/win/Release pwd = D:/src_tcl_orig/win/Release d = D expectedResult = D:/src_tcl_orig/win/Release ::env(HOME) = D: result = D:/src_tcl_orig/win/Release cd no longer changes to HOME, either test needs '/' added to setting home and expected result, or D: needs to resolve to absolute path not volume relative. Which it is, depends on what 'file normalize C:' should do in my previous message. ---------------------------------------------------------------------- Comment By: Daniel South (wildcard_25) Date: 2004-09-28 04:00 Message: Logged In: YES user_id=596509 Given the conditions:- current directory on 'C:' = 'C:/temp' current directory on 'D:' = 'D:/temp' pwd = 'C:/temp' currently case1 'file normalize C:' == 'C:/temp' == pwd case2 'file normalize C:/' == 'C:/' case3 'file normalize D:' == 'D:/' case4 'file normalize D:/' == 'D:/' if 'case1' equals 'C:/temp' then 'case3' should equal 'D:/temp' or should 'case1' equal 'C:/'? ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-09-27 15:00 Message: Logged In: YES user_id=32170 Fixed. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-09-27 11:24 Message: Logged In: YES user_id=32170 In this particular case, what should 'file pathtype ~' give. Currently Tcl defines all paths starting with '~' to be absolute paths, but the path here might be better as volumerelative. ---------------------------------------------------------------------- Comment By: Daniel South (wildcard_25) Date: 2004-08-31 12:18 Message: Logged In: YES user_id=596509 maybe i should have just left off the '\program files' bit :) step by step from the test:- % set pwd [pwd] C:/Program Files/Tcl/bin (bin) 2 % set d [string index $pwd 0] C (bin) 3 % file normalize ${d}: C:/Program Files/Tcl/bin (bin) 4 % set ::env(HOME) ${d}: C: (bin) 5 % cd () 6 % set result [pwd] C:/ ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-08-31 09:23 Message: Logged In: YES user_id=32170 Your last example is correct (but you have a problem with backslash quoting): % set a "c:\program files" c:program files You're using a volume-relative path, and so the result is perfectly correct. However, that doesn't change the fact that this test is showing up some sort of problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1018980&group_id=10894 |