#currentWorkingDirectoryPath is not correct on macOS when using drag and drop to open
Hi, OSPlatform>>currentWorkingDirectoryPath (used by Path>>workingDirectory, used by Metacello to resolve local paths) always answers '/' for me when I drag the image onto the VM to open. I'm sure that's a "feature" of macOS but it's very annoying. In addition, FileLocator imageDirectory answers the correct workingDirectory because it uses a primitive instead of the FFI call to getCwd(). Is this a known issue? Should I open a new one? Max
Hi Max, On Fri, 8 Mar 2019 at 08:21, Max Leske <maxleske@gmail.com> wrote:
Hi,
OSPlatform>>currentWorkingDirectoryPath (used by Path>>workingDirectory, used by Metacello to resolve local paths) always answers '/' for me when I drag the image onto the VM to open. I'm sure that's a "feature" of macOS but it's very annoying. In addition, FileLocator imageDirectory answers the correct workingDirectory because it uses a primitive instead of the FFI call to getCwd().
Is this a known issue? Should I open a new one?
This is known behaviour. #imageDirectory and #workingDirectory are distinct concepts. #imageDirectory, obviously, is the location where the image resides, while #workingDirectory is the current working directory for the process. It's unfortunate that MacOS sets cwd to "/" when starting applications through the GUI. It sounds like you are already aware of this, but just to be clear: if you start Pharo from a shell you should see #workingDirectory return the same value as `pwd` in the shell. I'm not a Mac user, so I don't know what other applications typically do, but maybe wrap the startup in a script that changes to something more sensible (in your case above it sounds like changing to the directory where the image is located). But modifying #workingDirectory to answer the image directory isn't a good idea as it breaks lots of other use cases. Cheers, Alistair
On 8 Mar 2019, at 8:33, Alistair Grant wrote:
Hi Max,
On Fri, 8 Mar 2019 at 08:21, Max Leske <maxleske@gmail.com> wrote:
Hi,
OSPlatform>>currentWorkingDirectoryPath (used by Path>>workingDirectory, used by Metacello to resolve local paths) always answers '/' for me when I drag the image onto the VM to open. I'm sure that's a "feature" of macOS but it's very annoying. In addition, FileLocator imageDirectory answers the correct workingDirectory because it uses a primitive instead of the FFI call to getCwd().
Is this a known issue? Should I open a new one?
This is known behaviour. #imageDirectory and #workingDirectory are distinct concepts. #imageDirectory, obviously, is the location where the image resides, while #workingDirectory is the current working directory for the process.
It's unfortunate that MacOS sets cwd to "/" when starting applications through the GUI. It sounds like you are already aware of this, but just to be clear: if you start Pharo from a shell you should see #workingDirectory return the same value as `pwd` in the shell.
I'm not a Mac user, so I don't know what other applications typically do, but maybe wrap the startup in a script that changes to something more sensible (in your case above it sounds like changing to the directory where the image is located). But modifying #workingDirectory to answer the image directory isn't a good idea as it breaks lots of other use cases.
Cheers, Alistair
Thanks Alistair. I suspected as much. In my case the solution will be to compose the path to the repository in the baseline by hand before passing it to Metacello (e.g. `repository: 'filetree:', (FileLocator imageDirectory) pathString, '...'`. Cheers, Max
participants (2)
-
Alistair Grant -
Max Leske