Hi Guile, http://forum.world.st/Working-directory-td4631865.html I think there is some discussions about that a while ago. Thierry 2015-08-26 11:32 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
(I cc the VM dev as this topic touches a bit the VM)
Hi, chasing a bug I found that FileSystem does not handle well the working directory of the system. The working directory of a process is the directory from where we started the process. That is, the directory from where we launched the VM with the image.
However, FileSystem has two problems with this: 1) it believes that the workingDirectory is where the image *is* and not where it was open. (Check: FileSystem workingDirectory). 2) if you try to use a relative file name FileSystem will use the working directory he believes instead of letting the primitive do his job. (Just open your image from another directory and do 'asd.txt' asFileReference fullName).
This problem becomes apparent when you use the launcher, or when you launch your image from other directory.
Now, I was checking with Santi how to obtain the working directory of the process and we saw that there are two primitives """"included""" in the VM as part of the OSProcess plugins to do it (Included as they are in the PharoVM build).
<primitive: 'primitiveGetCurrentWorkingDirectory' module: 'Win32OSProcessPlugin' >
AND
<primitive: 'primitiveGetCurrentWorkingDirectory' module: 'UnixOSProcessPlugin' >
So I'd like to propose: - include those primitives in the default VM (as we already have the ones to get the image file path and the vm file path). - Add methods calling those primitives in OSPlatform and subclasses - Change FileSystem to have the working directory work as expected.
What do you think? Guille