Re: [Pharo-dev] #currentWorkingDirectoryPath is not correct on macOS when using drag and drop to open
On 8 Mar 2019, at 8:33, Alistair Grant wrote: Hi Max, On Fri, 8 Mar 2019 at 08:21, Max Leske 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
Re: [Pharo-dev] #currentWorkingDirectoryPath is not correct on macOS when using drag and drop to open
Hi Max, On Fri, 8 Mar 2019 at 08:21, Max Leske 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
[Pharo-dev] #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
