Tcl Source Code

The sequence "cd \\; puts [glob *]" returns a list where 
each first character is lost.  This does not happen on 
WinNT4, but always on Win98SE.

Using "glob ./*" works as expected, though.

I suspect that this may also be the reason why exec 
fails (for example: "exec command /c dir"), complaining 
about not beign able to find COMMAND.COM.

This problem exists in ActiveTcl 8.4 beta (i.e. 8.4a4), 
and in the current cvs HEAD (i.e. 8.4a5).

I've looked in the glob code, which changed due to the 
new VFS layer, but have not been able to figure it out.

Logged In: YES 
user_id=32170

Ok, I've added the fix to my patch of another bug 
(including the 'stricmp' thing).  Thanks!

Logged In: YES 
user_id=1983

DIR problem solved: it requires tclpip84.dll, since 
COMMAND.COM is a 16-bit app on Win98.

Ouch.  The source comment say that tclpip84.dll has to live 
next to the tcl app/dll, but it can live in c:\windows as 
well - which seems slightly more appropriate (there is a 
similar issue with msvcrt.dll, which is required for tclkit 
but does not exist on Win95).

FWIW, I changed the comparison with .com to be case-
insensitive - not sure it matters here, but it sure looks 
like it would be better, i.e. tclWinPipe.c line 1434, strcmp 
-> stricmp.

Anyway... end of story.  All issues have been resolved... :o)

Logged In: YES 
user_id=1983

Hang on...

It does solve the glob, but not typing "dir" in an 
interactive shell:

 % dir
 couldn't execute "C:\WINDOWS\COMMAND.COM": no such file or 
directory

Note that this dir problem does not happen in Activetcl 8.4 
beta, unly in my own (more recent?) builds.

Shall I create a different bug report for this one?  
(Assuming it is not my own bug this time)

Logged In: YES 
user_id=1983

Yep, that did it (changed to \ to \\ of course).

Btw, the "short native form on 9x vs. long /'ed one on NT 
etc" is a horrible difference - I'd hope it gets documented 
in BLINKING RED - because this can easily trip over people 
who need to retain compatibility with 9x.

Ok, great.  Solved - thanks for the really quick turnaround.

Logged In: NO 

Hang on!  I just remembered that to solve the big slowdown 
on Win95/98 with the vfs code we had to make normalized 
paths on those platforms have backslashes (and be 
the 'short' form of a path).  On Win NT/2000/XP the 
normalized form has forward slashes and the 'long form'.

This means 'pwd' should be C:\ on 98, and the problem is 
around line 1730 in tclIOUtil.c.  How about using the 
following block of code there:

cwdDir = Tcl_DuplicateObj(cwd);
Tcl_IncrRefCount(cwdDir);
cwdStr = Tcl_GetStringFromObj(cwdDir, 
&cwdLen);
#ifdef __WIN32__
if ((cwdStr[cwdLen-1] != sep) && (cwdStr
[cwdLen-1] != '\\')) {
#else
if (cwdStr[cwdLen-1] != sep) {
#endif
    Tcl_AppendToObj(cwdDir, &sep, 1);
    cwdLen++;
    /* Note: cwdStr may no longer be a 
valid pointer */
}

Logged In: YES 
user_id=1983

Well, 'pwd' does the right thing.  It's "file normalize" that 
messes it up again.  With a non-existent dir (and going to 
ActiveTcl 8.4 beta to make sure it wasn't the extra VFS 
layer):

  file normalize c:/a  ->  C:/a

With an existing dir, though:

  file normalize c:/windows  ->  C:\WINDOWS

Logged In: YES 
user_id=1983

All of glob -dir / *, \\ *, C:/ * seem to return the expected 
values.  But [pwd] returns paths with backslahes, so it looks 
like (ii) is the issue here.

I'll chase this further, thanks for these very helpful notes.

Logged In: YES 
user_id=32170

What do these return:

glob -dir / *
glob -dir \\ *
glob -dir C:/

Logged In: YES 
user_id=32170

I can't really debug this since I don't have any Win98 
machines to test on at all.  However, the bug occurs for 
one of three potential reasons.  First off, the way 'glob 
*' in the new fs works is to do a 'glob -dir [pwd] *' and 
strip off the pwd (for reasons explained in the comments in 
the code).  What is happening therefore is that too much is 
being stripped off.

Why?  Back to the three potential reasons:

(i) there's a bug in the code doing the stripping, (around 
line 1730 in tclIOUtil.c)

(ii) there's an assumption in the code (in a variety of 
places, I believe), that '[pwd]' is a normalized path which 
does not end in a directory delimiter, _unless_ it is the 
name of a root volume, in which case it will end in a 
delimiter.  On Windows, normalized paths contain forward 
slashes, not backslashes.  So I would hope 'pwd' is 'C:/' 
in the above case.  (and not C:\\ or C:).  So, please check 
this out!  If 'pwd' is incorrect, then code elsewhere needs 
fixing.

(iii) since the stripping works simply be checking how 
long 'pwd' is, and removing that, if 'glob -dir [pwd] *' is 
returning the wrong answer, (e.g. it returns C:Windows, 
skipping the slash), then the fault lies in 
TclpMatchInDirectory in win/tclWinFile.c

Hope that helps you to track it down.

Vince.

File Added - 19512: globroot.txt