[Tcl-bugs] [ tcl-Bugs-2806250 ] glob, tilde string representation anomaly

[SourceForge.net <no...@so...>]

Bugs item #2806250, was opened at 2009-06-14 12:57
Message generated for change (Comment added) made by dgp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2806250&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 37. File System
Group: development: 8.6b1.1
>Status: Closed
>Resolution: Fixed
Priority: 8
Private: No
Submitted By: Julian Noble (juliannoble)
Assigned to: Don Porter (dgp)
Summary: glob, tilde string representation anomaly

Initial Comment:
  When a filename contains a tilde character 'file exists' may falsely return zero.
  The bug occurs when the filename as returned from glob is used.
  Any call to 'file normalize' - even without using the returned value will cause a subsequent 'file exists' to correctly return 1.

  When the path is entered directly in tclsh, or hardcoded into a script, file exists correctly returns 1.

  set folder {/usr/local/test/} 
  set files [glob -dir $folder -type f *] 
  foreach f $files { 
      #puts [file normalize $f] 
      puts "$f exists: [file exists $f]" 
  } 


Simply create a text file with the name "~test.txt" in the test 
folder. 


With the 1st puts commented, the output is: 
/usr/local/test/~test.txt exists: 0 


With the puts uncommented, the output is: 
/usr/local/test/~test.txt 
/usr/local/test/~test.txt exists: 1 


Tested on FreeBSD  8.6b1.1 2009-06-14 checkout.



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

>Comment By: Don Porter (dgp)
Date: 2009-08-20 11:18

Message:

Committed more radical patch to HEAD
for 8.6b2 that also removes some large chunks
of code complexity which had no obvious value.


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

Comment By: Don Porter (dgp)
Date: 2009-08-20 11:00

Message:

fix committed for 8.5.8.  Should see the
tests fileName-20.7,8 now pass.

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

Comment By: Don Porter (dgp)
Date: 2009-08-20 10:52

Message:

Version 2 of the patch also removes some
special workaround code in TclMakePathRelative()
that prevented it from doing the wrong thing when
the "tail" held a string starting with ~.  Since we no
longer permit that, we do not need the workaround.

Large comments questioning the rationale of some
bits of code, and pondering about their reform also
in the new patch.

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

Comment By: Don Porter (dgp)
Date: 2009-08-19 17:49

Message:

Attached a patch for 8.5


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

Comment By: Don Porter (dgp)
Date: 2009-08-19 13:25

Message:

The PATHFLAGS != 0 internal rep for path
values stores the path in two parts, a "head"
and a "tail".  Much of the code that operates
on this rep makes the assumption that the
"tail" is a relative path.  When a value starting
with ~ is permitted to get stored as the tail,
these assumptions no longer hold.


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

Comment By: Don Porter (dgp)
Date: 2009-08-18 13:42

Message:
committed test fileName-20.7 to
all branches to test for this bug.

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

Comment By: Donal K. Fellows (dkf)
Date: 2009-08-09 20:26

Message:
Sounds like a problem internal rep.

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

Comment By: Julian Noble (juliannoble)
Date: 2009-08-09 19:50

Message:
Title updated to remove reference to 'file normalize'.
It seems that various other operations on the string  (e.g subst) can be
used to coax a bad path representation to do the correct thing.
e.g
set f [string range $f 0 end] 



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

Comment By: Julian Noble (juliannoble)
Date: 2009-08-09 08:12

Message:
priority raised.
This issue has come up again on CLT.
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/2c8027298fe860f3/28cb705e1fb0e74d#28cb705e1fb0e74d

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

Comment By: Julian Noble (juliannoble)
Date: 2009-06-16 14:30

Message:
> cd /tmp/working/filenames.tcl

should read:

>cd /tmp/working

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

Comment By: Julian Noble (juliannoble)
Date: 2009-06-16 13:47

Message:
Verified that it does occur on Linux (CentOS) with 8.6b1.1
(but does not occur with 8.5.7 tclkit)

uname -a
Linux project-open-v33 2.6.18-53.1.21.el4 #1 SMP Tue May 20 09:34:19 EDT
2008 i686 i686 i386 GNU/Linux

This is the 3rd platform I've duplicated the bug on.
I'll explain it a bit more step by step - as I've found a couple of ways
the bug can be hidden.

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

create a folder structure  /tmp/working/examine

Make sure the examine folder contains only the ~test.txt  file
Save the following script as filenames.tcl - into the /tmp/working folder

set folder {/tmp/working/examine}
set files [glob -dir $folder -type f *]
foreach f $files {
    #puts [file normalize $f]
    puts "$f exists: [file exists $f]"
}


Make sure you run the script from within /tmp/working 
As mentioned in my other comment - if you run the script whilst your pwd
is /tmp/working/examine - the bug will be masked.  

> cd /tmp/working/filenames.tcl
> tclsh filenames.tcl
/tmp/working/examine/~test.txt exists: 0


----------------------------------------------------------
Note that if you run it with the full path name to the script - you won't
see the zero in the output.
ie it must be called as  'tclsh filenames.tcl'  not 'tclsh
/tmp/working/filenames.tcl'

Another weird thing is that if you add the following line to the top of
filenames.tcl - then suddenly the bug *does* appear when called as 'tclsh
/tmp/working/filenames.tcl'

puts stdout "pwd: [pwd]"


It seems to me that it's possibly somewhat different to bug 2511011 
because in this case we are supplying the -dir argument to glob and not
using -tail,  so we are always dealing with the complete path.  As far as I
can see - there should be no tilde/homedir substitution involved in this
case.





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

Comment By: Don Porter (dgp)
Date: 2009-06-15 14:42

Message:

Perhaps some detail is not getting
reported, and what's really happening
is some symptom of Bug 2511011?

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

Comment By: Don Porter (dgp)
Date: 2009-06-15 14:20

Message:

Can't reproduce on Linux with the tip of
any active branch.

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

Comment By: Julian Noble (juliannoble)
Date: 2009-06-15 11:17

Message:
Verified that bug occurs on windows vista x64 with Tcl 8.6b1.1
Does not occur with an 8.5.2 tclkitsh on that platform.

The bug appears to also relate in some way to the current working
directory.

If there is another copy of the file ~test.txt  within whatever directory
[pwd] refers to - then [info exists] returns 1.

The tilde seems to somehow cause the path to refer to the working
directory instead of the one being globbed upon.

(so for example - if the original script is placed in the same folder as
the one with the test file and run from there - the bug is not apparent)



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

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