Tcl Source Code

When I create symbolic links (on solaris and linux,
tcl8.4.4) using [file link -symbolic ...] command, the
created link file always points to an absolute path
even when a relative path is specified. This is causing
problems when the directory is moved around and the
links have to be deleted and re-created. Is this the
correct behavior (dictated by cross-platform support)?

It would be nice if the [file link] command behaved
like the unix 'ln' utility in this respect so that I
don't have to invoke [exec ln -s ...] for creating
relative links.

Hemang.

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

I don't see that this is specifically mentioned
anywhere in the docs
of the implementation.  It seems a byproduct of the
Tcl_FSGetNativePath
request returning a fully qualified path.  I'm not sure
whether this
is a bug, so I've cc'ed the implementor, Vince Darley.

Jeff Hobbs

Logged In: YES 
user_id=80530


Getting this backported for 8.4.13
would be really nice.  I realize it's
a tall order...

Logged In: YES 
user_id=330806

Are there any plans to backport this into 8.4? I would
really need it there!

-- Matthias Kraft

Logged In: YES 
user_id=80530

this was never backported?

Logged In: YES 
user_id=72656

Reopening for 8.4.6 backport.

Logged In: YES 
user_id=32170

Thanks -- all appears fine, as you say.  I'll mark that test
as nonPortable and close this.

Logged In: YES 
user_id=81875

This is on solaris 2.8.

godel:144> /tmp/hlavana/tcltk/bin/tclsh8.5
% info patch
8.5a0
% file mkdir td1
% set dir [pwd]
/tmp/hlavana
% cd td1
% set f1 [file normalize [file join .. td1]]
/tmp/hlavana/td1
% set f2 [file normalize [file join .. td2]]
/tmp/hlavana/td2
% file join .. td1
../td1
% file join .. td2
../td2
% file rename [file join .. td1] [file join .. td2]
% pwd
/tmp/hlavana/td2
% file rename [file join .. td2] [file join .. td3]
% pwd
/tmp/hlavana/td3
% 

It seems that it is possible to change the name of the
current directory on solaris platforms.

Logged In: YES 
user_id=32170

Can you tell me what 'file norm [file join .. td1]' and
'file norm [file join .. td1x]' give at this point in the
test suite?  Do they appear to be correct?  What is '$dir'
in this test?

thanks!

Logged In: YES 
user_id=80530


See Tcl Bug 747629.

Logged In: YES 
user_id=81875

Okay, I tried option (b) and now I get only one error:

fCmd.test

==== fCmd-9.14.2 file rename: comprehensive: dir into self
FAILED
==== Contents of test case:

    cleanup
    file mkdir td1
    set dir [pwd]
    cd td1
    set res [list [catch {file rename [file join .. td1]
[file join .. td1x]} ms
g] $msg]
    cd $dir
    set res

---- Result was:
0 {}
---- Result should have been (exact matching):
1 {error renaming "../td1" to "../td1x": permission denied}
==== fCmd-9.14.2 FAILED

File Deleted - 70333: 



File Added - 70362: linknorm.diff

Logged In: YES 
user_id=32170

Hmm -- I'll have to think about those.  I've updated
fileSystem.test to be more informative.  Could you please
re-run the tests with those changes in place?

(either (a) just update fileSystem.test from cvs and re-run,
or (b) update everything from cvs then apply the patch
attached to this report and re-run).

Logged In: YES 
user_id=81875

I am seeing some failures on solaris2.8 with your patch
applied to cvs head:

fCmd.test

==== fCmd-9.14.2 file rename: comprehensive: dir into self
FAILED
==== Contents of test case:

    cleanup
    file mkdir td1
    set dir [pwd]
    cd td1
    set res [list [catch {file rename [file join .. td1]
[file join .. td1x]} ms
g] $msg]
    cd $dir
    set res

---- Result was:
0 {}
---- Result should have been (exact matching):
1 {error renaming "../td1" to "../td1x": permission denied}
==== fCmd-9.14.2 FAILED

fileSystem.test

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

   string equal [file normalize [file join dir.link
linkinside.file foo]]  [file
 normalize [file join dir.file inside.file foo]]

---- Result was:
0
---- Result should have been (exact matching):
1
==== filesystem-1.7 FAILED


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

    file delete -force dir.link
    file link dir.link [file nativename dir.file]
    string equal [file normalize [file join dir.file
linkinside.file foo]]  [fil
e normalize [file join dir.link inside.file foo]]

---- Result was:
0
---- Result should have been (exact matching):
1
==== filesystem-1.9 FAILED


==== filesystem-1.10 link normalisation: double link FAILED
==== Contents of test case:

    file link dir2.link dir.link
    string equal [file normalize [file join dir.file
linkinside.file foo]]  [fil
e normalize [file join dir2.link inside.file foo]]

---- Result was:
0
---- Result should have been (exact matching):
1
==== filesystem-1.10 FAILED


==== filesystem-1.11 link normalisation: double link, back
in tree FAILED
==== Contents of test case:

    file link [file join dir2.file dir2.link] dir2.link
    string equal [file normalize [file join dir.file
linkinside.file foo]]  [fil
e normalize [file join dir2.file dir2.link inside.file foo]]

---- Result was:
0
---- Result should have been (exact matching):
1
==== filesystem-1.11 FAILED

File Added - 70333: linknorm.diff

Logged In: YES 
user_id=32170

Could you try this updated patch? -- it fixes the ~user
issue and also patches some generic normalization code so
that it can handle these relative links.  It would be very
helpful if you could run the file*.test tests after applying
this patch.

Logged In: YES 
user_id=81875

On unix systems, "~/foo" is first expanded by the shell
before passing it onto the link command. So such files will
have absolute paths, see below:

godel:271> ln -s ~/foo bar
godel:272> ls -l bar
lrwxrwxrwx   1 hlavana  eng           18 Dec 11 10:20 bar ->
/users/hlavana/foo
godel:273> 

I have verified that your patch work correctly for relative
links. As for the ~ chars, it should expand into absolute
paths, otherwise on unix the link is not created properly:

hlavana-u5:165> ./tcltk/bin/tclsh8.4
% file link -symbolic foo ~/ddts
~/ddts
% cat foo
cat: cannot open foo
child process exited abnormally
% file exists foo
0
% file exists ~/ddts
1
% exit
hlavana-u5:166> ls -l foo 
lrwxrwxrwx   1 hlavana  eng8           6 Dec 11 12:41 foo ->
~/ddts
hlavana-u5:167> cat foo
cat: cannot open foo
hlavana-u5:168>

As you can see, ~/ddts is a valid file but foo not exist.

File Added - 70240: unixlink.diff

Logged In: YES 
user_id=32170

Please try the attached patch.

Logged In: YES 
user_id=32170

I'll set about fixing this, but first a question.  Is a
symbolic link on Unix effectively just a link to an
arbitrary 'string' or is some pre-processing done first? 
For example, what should:

% file link -symbolic foo ~vince

do?  Should it genuinely link to '~vince' or should it first
expand '~vince' and link to the expanded version?

Logged In: YES 
user_id=32170

It's hard to say if this is a bug or a feature. On balance
(for Unix) I suppose it is a bug.  The solution is to modify
TclpObjLink's creation of 'target':

CONST char *target = Tcl_FSGetNativePath(toPtr);

so that it just uses 'Tcl_GetString' and a manual
Tcl_UtfToExternal conversion.  I don't know if Windows/MacOS
support such relative links or not.