Tcl Source Code

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.

Logged In: YES 
user_id=32170

All of this is now in CVS, so closing the bug.

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).

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?

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!

File Added - 103065: winFCmd.test.patch

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

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.

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?

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.

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:/'?

Logged In: YES 
user_id=32170

Fixed.

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.

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:/

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.