[BruceEel]

Yes, for things like PATH. But ASSIGN did more, you could essentially create a "device" (combining all ADD'ed things) that could be transparently accessed as such by other programs. It worked like a version of the Windows SUBST command accepting multiple arguments.

[stutonk]

Like a union mount?

[sime2009]

Yes, a lot like a union mount except that it was read only and easy to modify.

Assigns were often used for things that we today would stuff into an environment variable to represent an array of paths. Instead of an environment variable for setting the search path for shared libraries, on the Amiga you would just setup `LIBS:` and an application could find its libraries by opening `LIBS:MyFoo.library`. Similar story for $PATH. Amiga has `PATH:` which "contained" all of the executables in your path. Unlike unix style environment variables, assigns were system wide. (Amiga was a single user system.)

[BruceEel]

No direct experience with union mounts (I'm on Mac) but it sounds like those would do the trick.

[stutonk]

If it is indeed a union mount mechanism, then that's truly a remarkable feature. Reading the documentation makes it sound like something akin to an symbolic link but perhaps not in the actual filesystem; I still can't tell if it's implemented in the kernel/FS or just the shell (or to what extent the two are integrated). If it's just the shell then this seems to be a shining example of where the POSIX interface is holding us back. In Linux, they've tried to implement union mounts a number of times (as UnionFS, aufs, and OverlayFS) because it's almost too complicated to get right for Unix-style filesystems and you need a bunch of kernel-level code. Do you happen to know if it was possible to create the ASSIGNs programmatically? Does deleting/renaming files in the ASSIGN work like you'd hope?

[BruceEel]

Yes, it was indeed implemented at OS-level, you could point at the assigned name/alias from, say, a paint program and find the files/dirs you'd expect to see. Changes to files/dirs too worked as expected as far as I can recall (disclaimer: most recent Amiga experience -> 1994). It was also possible to create assigns programmatically with calls to the Amiga DOS library, see "dos.library/AssignPath" in http://amiga.nvg.org/amiga/reference/Includes_and_Autodocs_2...

    NAME
     AssignPath -- Creates an assignment to a specified path (V36)
    
       SYNOPSIS
     success = AssignPath(name,path)
     D0                    D1   D2
    
     BOOL AssignPath(STRPTR,STRPTR)
    
       FUNCTION
     Sets up a assignment that is expanded upon EACH reference to the name.
     This is implemented through a new device list type (DLT_ASSIGNPATH, or
     some such).  The path (a string) would be attached to the node.  When
     the name is referenced (Open("FOO:xyzzy"...), the string will be used
     to determine where to do the open.  No permanent lock will be part of
     it.  For example, you could AssignPath() c2: to df2:c, and references
     to c2: would go to df2:c, even if you change disks.
    
     The other major advantage is assigning things to unmounted volumes,
     which will be requested upon access (useful in startup sequences).
    
       INPUTS
     name - Name of device to be assigned (without trailing ':')
     path - Name of late assignment to be resolved at each reference
    
       RESULT
     success - Success/failure indicator of the operation
    
       SEE ALSO
     AssignAdd(), AssignLock(), AssignLate(), Open()