Haha, I didn't pay enough attention to see the difference between #workingDirectory and #home. Thanks for the clarification ! BTW, what I also wanted to add is that independent of the precise type you can always use the instances to do your job (open it, move it, etc ...).
On 14 Feb 2019, at 08:18, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi David & Sven,
On Thu, 14 Feb 2019 at 07:46, Sven Van Caekenberghe <sven@stfx.eu> wrote:
David,
On 14 Feb 2019, at 03:56, David Richards <david.i.richards.iii@gmail.com> wrote:
Hi community,
Consider:
| file | file := FileLocator workingDirectory . file fullName . "==> '/Users/dr/Documents/Pharo/images/Study (Pharo 7.0 - 64bit stable)'" file pathSegments . "==> #()"
How do we obtain path segments for the working directory?
Is this an edge case where pathSegments does not return a semantically consistent value?
Thanks David
A FileLocator is a bit special, it is usable, but not yet fully realised, more abstract.
You can use resolve. Consider:
FileLocator home pathString. "'/Users/sven'"
FileLocator home resolve pathSegments. "#('Users' 'sven')"
What Sven wrote is, of course, correct. But this is also an edge case:
FileLocator workingDirectory resolve pathSegments. "#()"
The reason in this case is because the directory is stored as a RelativePath. A RelativePath is resolved against the working directory, which in this case is the same thing, so no movement is required, and an empty path is used.
You can also try:
FileLocator workingDirectory asAbsolute pathSegments. " #('home' 'alistair' 'pharo8' 'pharo64.04')"
Just for added confusion, FileLocator class>>workingDirectory is also a special case. Most of the methods in the origins protocol return an instance of FileLocator. But FileLocator class>>workingDirectory returns an instance of FileReference.
HTH, Alistair