Tcl Source Code

The new Tcl_FSGetTranslatedStringPath appears to be
the VFS-aware counterpart of Tcl_TranslateFileName.
However, they differ in their translation of file
names on non-Unix platforms.

On Windows, Tcl_TranslateFileName converts all '/'
separators to '\'.  The new routine does not.

On Mac, Tcl_TranslateFileName and the new routine
differ on how they manage runs of ':'.

In particular, if I rewrite Tcl_TranslateFileName
as a wrapper around Tcl_FSGetTranslatedStringPath,
then the following tests fail:

cmdAH-19.7
filename-10.2
filename-10.3
filename-10.13
filename-10.15
filename-10.16
filename-10.17
filename-10.18
filename-10.21
filename-10.22

Logged In: YES 
user_id=80530

That approach would be correct and more efficient on
unix-style paths, but would be completely wrong for
the mac-style paths.  It seemed somehow "cleaner" to
use existing TclpNative* routines to cover the platform
differences rather than add more platform-specific
processing directly in SetFsPathFromAny itself.

That said, I certainly have no objection if later on you
replace this correct implementation with a different
correct implementation that's also more efficient.

Logged In: NO 

This looks fine.  A more efficient solution _might_ be 
possible (I haven't looked closely enough to be absolutely 
sure), by simply skipping any extra separators and then 
using the existing 'JoinToPath' stuff.   Anyway, the 
existing solution looks good.  -- Vince.

Logged In: YES 
user_id=80530

committing fix to HEAD (8.4a4).  If you find problems
with it, Vince, we can back it out.

File Added - 16643: tilde.patch

Logged In: YES 
user_id=80530

Yes, and see tests filename-10.{13,15,16}.

Here's a patch that fixes the problem.  Please
review that it fits in with the VFS system design.

Logged In: YES 
user_id=32170

What should the correct result of '~//foo' be?  Is it 
defined to be the same as '~/foo'?

What about on MacOS?  What are ~::foo and ~:::foo?

Vince.

Logged In: YES 
user_id=80530


Here's a specific bug related to the trouble seen on
Macs.  The tilde-expansion in SetFsPathFromAny is
flawed in the way it handle separators right after
the expanded tilde.  This is most easily seen by the
way it converts the string ~//foo to the path /foo.

Logged In: YES 
user_id=80530


Here's a specific bug related to the trouble seen on
Macs.  The tilde-expansion in SetFsPathFromAny is
flawed in the way it handle separators right after
the expanded tilde.  This is most easily seen by the
way it converts the string ~//foo to the path /foo.

Logged In: YES 
user_id=80530


Here's a specific bug related to the trouble seen on
Macs.  The tilde-expansion in SetFsPathFromAny is
flawed in the way it handle separators right after
the expanded tilde.  This is most easily seen by the
way it converts the string ~//foo to the path /foo.

Logged In: YES 
user_id=80530

OK, that will take care of me on Windows and Unix.

After looking over filename.n, it appears to me that
Tcl_FsGetTranslatedPathString may be buggy in its
interpretation of multiple ':' on Mac.  '::' mean
parent directory, ':::' means parent of parent, etc.,
but it's not clear that meaning is being preserved.

More details after I look it over.

Logged In: YES 
user_id=32170

My recommendation would be to implement those lines 
as 'Tcl_FSGetTranslatedPathString', followed by (on 
Windows) a manual translation of forward slashes to 
backslashes to yield the desired 'native path name'.

The rest of the Tcl core's C code doesn't really care about 
the result of the Tcl-level command 'file nativename' (the 
core uses the caching Tcl_FSGetNativePath), so I think it's 
ok to do things like this.

An alternative (more complex) would be to add a new Tcl_FS 
command which returns the relative part of the normalized 
native path, but that's quite a complex operation.

Daniel Steffen may need to look at how the code handles 
runs of ':' if there are problems there.

Hope that helps; sorry not to be more actively helpful 
right now.

Logged In: YES 
user_id=80530

Let me ask it this way then.  The command [file nativename]
is implemented in lines 1016-1032 of tclCmdAH.c as:

1016         case FILE_NATIVENAME: {
1017             char *fileName;
1018             Tcl_DString ds;
1019
1020             if (objc != 3) {
1021                 goto only3Args;
1022             }
1023             fileName = Tcl_GetString(objv[2]);
1024             fileName = Tcl_TranslateFileName(interp, 
fileName, &ds);
1025             if (fileName == NULL) {
1026                 return TCL_ERROR;
1027             }
1028             
Tcl_SetStringObj(Tcl_GetObjResult(interp), fileName,
1029                              Tcl_DStringLength(&ds));
1030             Tcl_DStringFree(&ds);
1031             return TCL_OK;
1032         }

If I want to re-implement so that Tcl_TranslateFileName()
is not called, but some of the new VFS-aware routines are
called instead, what should I call to get the same results?

Logged In: NO 

Tcl_FSGetTranslatedStringPath is designed _not_ to convert 
backslashes, (unlike the older string based API), so those 
tests will need changing if they now claim to test the new 
routine (this is documented in the source code, but perhaps 
not in the docs).  Could you please list the actual bad 
test results instead of just the numbers (else, I will have 
time in a couple of weeks to look at this properly).

More generally, 'Tcl_FSGetNormalizedPath' is the ideal 
thing to use under most circumstances (but, note, it 
returns an absolute path).

-- Vince.

Logged In: YES 
user_id=80530

Nope.  Tcl_FSGetNativePath is much worse.

Logged In: YES 
user_id=80530

Hmmm.... Tcl_FSGetNativePath might be what I want instead.