Topic       : Documentation for Thing
Author      : Arno Welzel/Thomas Binder/TransAction
Version     : thing.hyp 1.27E (23/8/1998)
Subject     : Documentation/Shells
Nodes       : 269
Index Size  : 6336
HCP-Version : 4
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : %I
@help       : %Hilfe
@options    : +g -i -s +y +zz -t4 -d10
@width      : 75
@hostname   : THING   
View Ref-FileWhat are symbolic links?                                              Thing

A symbolic link (⇨*Symbolic links are usually called 'aliases'
in connection with MagiC (probably due to 
the influence of the MacOS since MagiC Mac),
though they have little or nothing in common
with the shell-aliases known from Mupfel, for
instance.
) is like a file whose contents are a list of files or 
folders. If a symbolic link is accessed (be it as a file or as a portion of
a path) its destination will be read internally and its filename replaced 
with this one.

For instance, if the entry C:\GEMSYS\ASSIGN.SYS is a symbolic link to 
..\NVDI\ASSIGN.SYS, then on accessing C:\GEMSYS\ASSIGN.SYS the contents 
of the link is read and substituted for ASSIGN.SYS, thus creating the 
access path C:\GEMSYS\..\NVDI\ASSIGN.SYS, which is synonymous with 
C:\NVDI\ASSIGN.SYS.

An absolute symbolic link is one in which the destination starts with 
a backslash or a drive letter. In that case after the operating system 
reads the link contents the complete previous path is replaced by the 
destination. So if, say, U:\etc is a symbolic link to the directory D:\etc, 
then accessing U:\etc in reality always refers to D:\etc.

Some notes and tips for handling symbolic links:

 ∙ The only thing a symbolic link knows about its destination is the path 
   specification, which may well point nowhere (i.e. to a non-existing 
   file or a non-existing directory).

 ∙ The destination of a symbolic link does not know that such a link 
   exists. As a result a symbolic link cannot be automatically altered 
   if the destination file is renamed, moved or deleted. In such cases 
   it just points nowhere.

 ∙ Symbolic links can be nested, i.e. a symbolic link can point to 
   another symbolic link, but one has to take care that one doesn't
   create endless loops (a is a symbolic link to b, b a symbolic link to 
   a), which are punished by an error message (ELOOP, -80) when accessed.

 ∙ If one lets a symbolic link point to an application then it will not 
   find its resource and other supplementary files as a rule when started 
   via the link. This is due to the fact that outwardly it was started 
   with the link's path specification and the required files are not 
   present in this directory.

   So if, say, C:\programs\qed.app is a symbolic link to D:\qed\qed.app,
   when qed is started via the symbolic link it will look for the file 
   default.qed (among others) in the directory C:\programs. Naturally no 
   such file exists there, so qed complains.

   This problem may be overcome by creating symbolic links for the required 
   supplementary files as well, or by working with links to directories. 
   In the above example it would be better to create a symbolic link 
   C:\programs\qed that points to D:\qed; with that one can start qed 
   without problems as C:\programs\qed\qed.app.

   Another possibility would be for Thing to check before starting programs
   whether the path specification is a symbolic link, and then to start the
   destination if appropriate. However this is not yet available and to 
   some extent contradicts the philosophy of symbolic links.

 ∙ Symbolic links with relative path specifications should only be moved 
   together with their destinations (and vice versa), as otherwise they 
   will point nowhere and will have to be adapted to the new path.

   Absolute path specifications, on the other hand, have the disadvantage 
   that the links, but not the destinations, may be moved. Furthermore 
   they are difficult to distribute in tar archives (the only archive 
   format I know that can store symbolic links as such) unless the 

   recipient has exactly the same directory and drive structure.

 ∙ Thing displays symbolic links in text and mini-icon mode in italics 
   in order to identify its special properties. Symbolic links whose 
   destination does not exist are drawn by Thing greyed out in all modes, 
   but can be selected nevertheless.
 
   The 'File - Show Info... (Files/Folders)' also displays the destination
   for symbolic links , though they cannot be altered there (yet?).


 ∙ Thing basically deletes only the symbolic links themselves and never
   their destinations. When copying files one can use  right Shift  or the
   confirmation dialog to specify whether the links or their destinations 
   are to be duplicated.