On 14/06/20 7:27 pm, Jakob Reschke wrote:
> In my understanding and in most of the libraries I have seen, a path is 
> a sequence of parts that mostly make up the directories and the last 
> element is the name of either a file or a directory. You may represent 
> the whole thing in a single string with a separator between the 
> elements.
This hierarchical name space breaks down these days because of links and 
bind mounts. On unix, names are just links to a file object. There can 
be multiple links (within or even external to a filesystem). Therefore, 
the interpretation '..' differs from system to system.

> An agreement between image and plugin never to pass relative paths 
> between each other could make sense to me. But I still don't see the 
> value of distinguishing relative paths and incomplete paths, or how 
> ./foo/bar would be any more or less ambiguous for further processing 
> than just foo/bar. In both cases you need to know the startpoint (.) on 
> both sides (image, plugin), or one side will not know what it is talking 
> about.

If I pass "startup.st" as a document name to the VM, 
primitiveFileOpen("startup.st", ...) has the option of resolving paths 
by looking up a set of directories whereas if the path is given as 
./startup.st primitiveFileOpen("./startup.st", ...) has to look in CWD 
only. Currently, FileDirectory forces "startup.st" to mean 
imagePath/startup.st only, even if the vm is not started from the image 
directory.

e.g. Suppose app/ contains startup.st bin/ and shared/. Then this will fail:

    app$ bin/squeak shared/squeak.image startup.st

The FileDirectory should just be a tuple (container, entry) and move all 
  platform-specific stuff into FilePlugin.

> Subbu, you write about a platform-specific set of paths to look up. Do 
> you mean resolving against environment variables such as $PATH?
Yes. Plugins can use env variables to guide path resolution. The unix vm 
already uses env variables like SQUEAK_VM, SQUEAK_IMAGE, SQUEAK_USERDIR 
to avoid hard-coded paths in the image. This means Squeak applications 
could place a startup document in, say, $HOME/.squeak/startup.st or 
/etc/squeak/startup.st and have the image open it with just 'startup.st' 
without hard-coding the full path.

Regards .. Subbu