Tcl Source Code

Bytecompiling [uplevel]ed scripts (see uplevel.patch below) causes filesystem-1.11 to fail.

This seems to be due to improper spoiling of some intrep when the value is stored as a literal? It looks similar to [Bug #1972867], but filesystem-1.11 test is not so easy to run in isolation (it relies on some previous tests having been run?).

Logged In: YES 
user_id=80530
Originator: NO


backporting complete.

Logged In: YES 
user_id=80530
Originator: NO


Sleep is good.  Better fix committed to HEAD.

Logged In: YES 
user_id=80530
Originator: NO


committed to HEAD for 8.6a1.
needs backport.

Logged In: YES 
user_id=80530
Originator: NO


Distributors of browsers that crash
deserve death.

I had a lengthy comment to accompany
that patch.  All lost when my attempt
to upload the patch file brought the
browser down.  I'm in no mood to duplicate
it now.

This fix is a hack to correct a bug
in Tcl_FSGetTranslatedPath.  It's not
elegant, but I think forcing us through
string reps at least gives us something
we know will work, without requiring me
to reverse engineer the whole "path"
Tcl_ObjType.

The code getting replaced by this
patch was simply wrong wrong wrong.
It forced a complete normalization of
the path, and the whole "point" of a
translated path is that it is an
expansion of ~ **without** forcing a
full normalization.  In particular,
a relative path was being coerced into
absolute form.

Others are welcome to contribute better
fix(es).

File Added - 282178: 1972879.patch

Logged In: YES 
user_id=80530
Originator: NO


here's the patch.
File Added: 1972879.patch

Logged In: YES 
user_id=80530
Originator: NO


line 940, tclUnixFile.c

Logged In: YES 
user_id=80530
Originator: NO

dgpconfirmed that forcing a shimmer of the value {..} is sufficient to make test filesystem-1.11 pass again.
dgpso I bet the shared literal of that relative pathname is getting a full path cached in it
dgp...and since [pwd] hasn't changed, that's getting used in an improper way
dgpI fear this is wrapped up in an old debate about how [file link] is supposed to treat relative pathnames in the target value

Logged In: YES 
user_id=80530
Originator: NO

dgpthe difference is whether or not [file link] is compiled
dgpwhy that difference makes a difference is.... mysterious
dgpdrilling down, using [eval] on just the [file join .. dir2.link] part is enough.
dgpIck.  filesystem-1.11 depends on filesystem-1.10 ?
dgpThis is probably an actual bug
dgpcd ~
akuSeeing that I remember that one time somewhere I had to replace a [file join x y] with x/y, because the join command gave bogus results, and x/y didn't. Maybe because the latter forced everything through the string rep. Could of course be an unrelated problem in the path intrep. ... Found it
aku2007-08-08  Andreas Kupries  <[email protected]>

        * inplace.test: Fixed failures of some tests on Windows.

        * fileutil.tcl: Working around a possible bug in the handling of
          path intreps by the core, on Windows. See commentary in
          'fullnormalize', and 'find.setup' (f_setupcircle).

Logged In: YES 
user_id=202636
Originator: NO

Possibly the following from Windows XP are relevant:
==== filesystem-1.3 link normalisation FAILED
==== Contents of test case:

    testPathEqual [file normalize [file join dir.dir foo]]  [file normalize [file join dir.link foo]]

---- Result was:
not equal: C:/opt/tcl/src/kitgen/8.6/tcl/win/dir.dir/foo C:/opt/tcl/src/kitgen/8.6/tcl/win/dir.link/foo
---- Result should have been (exact matching):
1
==== filesystem-1.3 FAILED



==== filesystem-1.4 link normalisation FAILED
==== Contents of test case:

    testPathEqual [file normalize [file join dir.dir inside.file]]  [file normalize [file join dir.link inside.file]]

---- Result was:
not equal: C:/opt/tcl/src/kitgen/8.6/tcl/win/dir.dir/inside.file C:/opt/tcl/src/kitgen/8.6/tcl/win/dir.link/inside.file
---- Result should have been (exact matching):
1
==== filesystem-1.4 FAILED

Logged In: YES 
user_id=148712
Originator: YES

That patch has been committed to HEAD now

Logged In: YES 
user_id=148712
Originator: YES

That patch has been committed to HEAD now

Logged In: YES 
user_id=80530
Originator: NO


Any relation to 953284?

File Added - 279078: uplevel.patch