An analysis of the situation so people out of context can understand better the forces in play here :)
��- Working directory and files constant property: files defined using a *relative path* are created relative to the working directory.
�� �� In other words:��
�� �� �� ��File named: 'something/other/myfile.txt'
�� �� will be created in FileSystem workingDirectory.
�� �� This was always like this when we used the file primitives.
�� �� The diverging behaviour was introduced actually by FileSystem: FileSystem used to create by default all files relative to the image directory. And at some point all tools adapted to that and the correct behaviour was hidden.
-��Change in working directory:��Before, pharo always satisfied the following property:
�� �� �� ��FileSystem workingDirectory = FileSystem imageDirectory
����
�� ��This is no longer true for every case.
�� ��Now, the workingDirectory is aligned with the process' working directory (This is the equivalent to getcwd() in C, pwd command in linux, $PWD in bash).
�� ��I explained a couple of weeks ago in an email, this may break some eggs, specially for those tools that wrongly assume FileSystem workingDirectory = FileSystem imageDirectory.
�� ��Tools requiring imageDirectory should use imageDirectory explicit. At least that will keep backwards compatibility.
�� ��For other cases, we should probably study them case by case and provide a satisfying solution.
�� ��This change does however not affect everybody, and most of the times it is backwards compatible:
�� ��** This does not affect in general people launching usually pharo from the command line and using zeroconf:
�� �� �� ��$ ./pharo Pharo.image
�� �� �� ��## Here, FileSystem workingDirectory = FileSystem imageDirectory because I launched my image from the directory where my image is!
�� ��** This does affect people that are:
�� �� �� - launching Pharo doing double click.
�� �� �� �� �� In this case, we saw with Denis and Pavel a week ago that osx assigns as working directory the root directory "/"
�� �� �� �� �� Users of files should be aware of this and applications should not abuse the workingDirectory. If they want to enforce the imageDirectory, they should do so explicitly.
�� �� ��- launching Pharo from the pharo launcher (taken from this thread)
�� �� �� �� ��Apparently the pharo launcher is launching the image from a directory internal to the launcher. This means that the working directory will be assigned to that directory. I'd expect that the directory structure is private to the launcher...
�� �� �� �� I find even strange that the launcher puts pharo-local where the image is...
��
Given this, possible solutions are:
�� - On fileout, chose a correct directory when launched from double click
�� - Make the pharo launcher set a well-known working directory when launching an image
�� �� �� - one possibility is to set $HOME
�� �� �� - another possibility is to set the image directory (this will keep backwards compatibility)
@Stef: about the #fullname. It is not there because it is not implemented :). We did not have the possibility of calculating a correct full path until a couple of weeks ago (and before, even if we did so, it couldn't be done without introducing a dependency to a non-kernel package).
