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 <[email protected]>: > (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 >
