TIP 99: Add 'file link' to Tcl

Login
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2017 Conference, Houston/TX, US, Oct 16-20
Send your abstracts to tclconference@googlegroups.com
by Aug 21.
Author:         Vince Darley <vincentdarley@users.sourceforge.net>
State:          Final
Type:           Project
Vote:           Done
Created:        11-Jun-2002
Post-History:   
Tcl-Version:    8.4

Abstract

Tcl can read links, but cannot create them. This TIP proposes adding a file link subcommand to allow cross-platform creation of links.

Proposal

Add a new subcommand with the following syntax:

      file link ?-linktype? linkName ?target?

If only one argument is given, that argument is assumed to be linkName, and this command returns the value of the link given by linkName (i.e. the name of the file it points to). If linkName isn't a link or its value cannot be read (as, for example, seems to be the case with hard links, which look just like ordinary files), then an error is returned.

If 2 arguments are given, then these are assumed to be linkName and target. If linkName already exists, or if target doesn't exist, an error will be returned. Otherwise, Tcl creates a new link called linkName which points to the existing filesystem object at target, where the type of the link is platform-specific (on Unix a symbolic link will be the default). This is useful for the case where the user wishes to create a link in a cross-platform way, and doesn't care what type of link is created.

If the user wishes to make a link of a specific type only, (and signal an error if for some reason that is not possible), then the optional linktype argument should be given. Accepted values for linktype are -symbolic and -hard.

When creating links on filesystems that either do not support any links, or do not support the specific type requested, an error message will be returned (in particular Windows 95, 98 and ME do not support any symbolic links at present, but Unix, MacOS and Windows NT/2000/XP (on NTFS drives) do).

The TIP proposes implementing:

           Unix,MacOSX      Win-NTFS           MacOS
symbolic:      yes        directories-only      yes
hard:       files-only     files-only           no

This also leaves the avenue open, in the future, for the addition of other link types (e.g. Windows shortcuts) through additions to list of acceptable linktypes. This TIP only proposes adding the above options.

This means that a general [file link $linkname $target] should always succeed on the above platforms (for both files and directories), but uses of -hard or -symbolic could fail, depending on the current platform, and the type of the path.

Rationale

There are many requests on comp.lang.tcl for this functionality (see http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF8&oe=UTF8&threadm=4dd3bea3.0206100250.95eeb4e%40posting.google.com&rnum=1&prev=/&frame=on for a recent thread), and if Tcl can read links (file readlink, file lstat), it really ought to be able to write them.

Discussion has shown that both symbolic and hard links are desirable, and that for cross-platform use a general-purpose file link which creates something is useful.

Some users would prefer hard links to be the default, but on balance most people commenting seemed to prefer symbolic links as default. This has the added benefit that symbolic links will then be the default on MacOS, Unix and Windows for everything, except files on WinTcl (where hard-links are required).

Alternatives

There is no cross-platform alternative available. TclX provides a link command for Unix only, and Unix platforms can also use exec ln ?-s? command to achieve the same effect.

Reference Implementation

Tcl contains a testfilelink command in generic/tclTest.c, which is a partial implementation used by the test suite. For a full implementation of this TIP, including the -linktype switch, see:

_ http://sourceforge.net/tracker/index.php?func=detail&aid=562970&group\_id=10894&atid=310894 _

which includes extensive docs and tests.

Copyright

This document has been placed in the public domain.

History