[Tcl-bugs] [ tcl-Bugs-1072136 ] change to tcl_findLibrary breaks freewrap

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1072136, was opened at 2004-11-23 21:51
Message generated for change (Comment added) made by cjmcdonald
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1072136&group_id=10894

Category: None
Group: current: 8.4.8
Status: Open
Resolution: Invalid
Priority: 9
Submitted By: Colin McDonald (cjmcdonald)
Assigned to: Don Porter (dgp)
Summary: change to tcl_findLibrary breaks freewrap

Initial Comment:
A recent change to tcl_findLibrary in auto.tcl,
released in Tcl 8.4.8, breaks freewrap. 

For all platforms freewrap stores its Tcl & Tk
library files in a zip based virtual filesystem,
under directories named /tcl & /tk. These
directories are pointed to by the TCL_LIBRARY &
TK_LIBRARY environment variables set in the
application initialisation.

The recent change to tcl_findLibrary introduced
use of file normalize in the section "# uniqify
$dirs in order". Unfortunately under Windows, file
normalize changes the /tk directory path by
treating it as a volume relative name, and
applying the default device name e.g to become
D:/tk. The result of this is that Tk fails to find
its library files and freewrap doesn't initialise.

Note that freewrap is not using the modern tcl
virtual file system api. Instead it is using the
old TclPro hooks, which may explain why file
normalize manipulates /tk as a Windows path.

Removing the file normalize fixes the problem.

----------------------------------------------------------------------

>Comment By: Colin McDonald (cjmcdonald)
Date: 2004-11-25 10:26

Message:
Logged In: YES 
user_id=883691

I have tested my installation with the following, and it enables
freewrap to work successfully:

    # uniquify $dirs in order
    array set seen {}
    foreach i $dirs {
	if {[info exists seen($i)]} { continue }
	set seen($i) ""
	lappend uniqdirs $i
    }
    set dirs $uniqdirs

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2004-11-25 00:46

Message:
Logged In: YES 
user_id=80530

A serious bug (or two?) escaped in Tcl 8.4.8,
so there will be a Tcl 8.4.9 pretty soon.

Would it help buy freewrap some
bug fixing time if line 133 of auto.tcl
were changed from

        lappend uniqdirs $norm
to
        lappend uniqdirs $i

That way, [tcl_findLibrary] would
only unquify its search list, and not
also normalize its entries.

There's still a real bug in freewrap
if it can't work compatibility with
[file normalize], and it should be fixed,
but if this change helps keep freewrap
functioning in the Tcl 8.4 series, I'm
willing to make it.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2004-11-24 15:15

Message:
Logged In: YES 
user_id=80530

ok, so appears this is really
a problem in freewrap, and should
be fixed there.  Incompatibilities
with [file normalize] likely go much
deeper than [tcl_findLibrary].

----------------------------------------------------------------------

Comment By: Vince Darley (vincentdarley)
Date: 2004-11-24 13:16

Message:
Logged In: YES 
user_id=32170

Ok, so freewrap depends on being able to intercept a
particular string representation of a file ('/tcl'), and as
such init.tcl's new approach of converting that string
representation into a real path (by normalization) means
that freewrap can no longer intercept what it wants.

The root of the problem is that freewrap is trying to
intercept a path which (on Windows) is not fixed -- the real
interpretation of '/tcl' changes depending on the current
working directory.

So, anyway, it's not a filesystem bug. 

----------------------------------------------------------------------

Comment By: Colin McDonald (cjmcdonald)
Date: 2004-11-24 12:53

Message:
Logged In: YES 
user_id=883691

My concern with this problem is that moving
from 8.4.7 to 8.4.8 in the stable 8.4.* release
series breaks freewrap, a deployment tool which
is used by many people.

Undoing the change in tcl_findLibrary does
actually workaround the problem.  Access to files
in the freewrap zip file system is expected to be
pretty simple i.e. read only, no writing, no
globbing and no file normalize (which did not
even exist when the TclPro hooks were
developed).  It is not a full-blown virtual file
system in the (excellent) sense of your modern
interfaces.

The change to tcl_findLibrary introduces a
dependency on file normalize for successful
access to the tk_library files.  As it does not
behave as expected for the freewrap /tk files
then freewrap breaks.  I think it is a bit unfair
to say that freewrap is dependant on buggy
behaviour in Tcl - it is dependant on the
expected behaviour and use of the TclPro hooks as
they were originally implemented.

I can see that your suggestion of freewrap:/ may
work - but would intoduce platform dependant code
into freewrap, with different mount points for
Unix & Windows.

I will notify the freewrap author, Dennis LaBelle
of this problem and discussion.  Hopefully he
will comment.

----------------------------------------------------------------------

Comment By: Vince Darley (vincentdarley)
Date: 2004-11-24 10:13

Message:
Logged In: YES 
user_id=32170

Under Windows paths starting with '/' are _defined_ to be
volume relative, therefore Tcl's behaviour is correct. Now
it could be there's some bug you have found (certainly a
number of volume-relative bugs have existed in Tcl and many
have been fixed in the last 12 months).

However, the more general point is that freewrap's use of
'/tcl' and '/tk' is not correct, and should not have worked
in the past -- i.e. freewrap relied on Tcl not having
correct handling of volume relative paths, it seems.

A possible resolution is for freewrap to claim those paths
as absolute by mounting a new volume, like this:

vfs::filesystem mount -volume /tcl "#not sure what goes here"

(but I see you're not using modern Tcl interfaces).

Then Tcl will not treat that path as volume relative (but I
would be quite wary of this approach, since it is in some
sense fundamentally incompatible with the WinTcl
filesystem).  Better would be to mount a new filesystem:
freewrap:/ with 'tcl' and 'tk' as subdirectories.

In summary:

* freewrap's use of '/tcl' is relying on bugs in old
versions of Tcl
* many volume relative bugs have been fixed, it is possible
there are more, but Tcl's treatment of '/tcl' as volume
relative is correct.

Question: does undoing the change in tcl_findLibrary
actually workaround the problem?  (If so, there is a bug in
Tcl still, in its usage of the old char-based TclPro hooks,
if not, then it just shows that volume relative paths are
now treated correctly).

I hope that helps.  Do feel free to file bugs in Tcl's
volume-relative file treatment, if any still exist, but
beyond that this seems to be a freewrap problem, really.

So, don't know what to suggest, except that I don't see us
making any filesystem changes to accomodate this behaviour.
Probably using 'freewrap:/' is the best bet.

Vince.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2004-11-23 22:01

Message:
Logged In: YES 
user_id=80530

sounds like filesystem problems to me.

if $path and [file normalize $path] do not
point to the same file, then something
in the filesystem support code is broken.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1072136&group_id=10894

[Tcl-bugs] [ tcl-Bugs-1072136 ] change to tcl_findLibrary breaks freewrap

The Tool Command Language implementation

[Tcl-bugs] [ tcl-Bugs-1072136 ] change to tcl_findLibrary breaks freewrap