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:
$ wget get.pharo.org/...
$ ./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).
On Thu, Nov 9, 2017 at 9:43 AM, Christophe Demarey <
christophe.dema...@inria.fr> wrote:
> Hi Stefan,
>
> > Le 8 nov. 2017 à 15:56, stephan <step...@stack.nl> a écrit :
> >
> > I run into all kinds of issues with the directory structure used by the
> new PharoLauncher. pharo-local seems to be shared now for multiple images.
>
> I never saw this issue.
> PharoLauncher does not have influence on the pharo-local directory of
> launched images. pharo-local directory is located in the same directory as
> the image run.
>
> in a Pharo 6.1 image:
> localDirectory
> ^ self class userLocalDirectory
> ifNil: [ (self imageDirectory / self class
> defaultLocalDirectoryName) ensureCreateDirectory ]
>
> userLocalDirectory
> ^ UserLocalDirectory ifNil: [
> FileLocator workingDirectory / self
> defaultLocalDirectoryName ]
>
>
> Maybe you run Pharo 7 images and this change « Build #203:
> 05723-Default-Working-Directory » has a side effect?
>
> > That makes using configurations practically impossible as they are not
> expecting to have to deal with pre-downloaded older and newer monticello
> files. The missing sources files is less of a problem.
> >
> > Stephan
> >
> >
>
>
>
--
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - *http://www.cnrs.fr
<http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
