Hi Guillermo, On Fri, Jun 30, 2017 at 10:12:32AM +0200, Guillermo Polito wrote: > On Fri, Jun 30, 2017 at 9:56 AM, Alistair Grant <akgrant0...@gmail.com> wrote: > > Rajula, thanks for your write-up. > > As the person who pushed Rajula to send his email I feel I should > respond. > > While I'm in favour of Rajula's proposed changes, scripting in > particular will be much easier, I think we need to make the change > generally known as it will not always be obvious, e.g. at the moment I > can rely on: > > '../init/mystartup.st' asFileReference fileIn > > to always work with the current definition since my init directory is > always next to the image directory. After Rajula's changes I > will need to do something like: > > (FileLocator imageDirectory resolve: '../init/mystartup.st') fileIn > > > That's not true. It depends from where the image is launched. If you're > running > from the command line, > > $ pharo Pharo.image eval " 'someFile' asFileReference fullName " > > will be a file relative to the path of the image, if you open the image from > where it is located (ie, working directory = image directory).
Feel free to ignore this section, it isn't important to the conclusion... But that's my point - it depends on where the image is launched. If I want to be sure that the file will be found, I need to resolve from the image directory, not the process current working directory. Using the current definition of defaultWorkingDirectory I don't need to worry about this. > This is yes different when you're > 1) deploying the image in one directory, but you're using it from another one > $ someDir/pharo someOtherDir/Pharo.image eval " 'someFile' > asFileReference > fullName " > > But then, why working directory should be image directory and not VM > directory? Just historical reasons? > That's a buggy convention. And people who know what a working directory is > will perceive it as even buggier. > > 2) starting the process from a graphical environment (ie, double click in an > executable app) > In that case, the OS usually sets as working directory the current user > home directory, or the user "desktop" directory. > > In any case, > - we should have a good default, I think that following the principle of > least > surprise we should use as working directory what the OS means by working > directory. This is the important bit on which we all seem to agree. :-) > - Applications in general should be explicit with their file management. > Each > OS has different locations to store different things (data, settings, > libraries, executables)... FileLocator helps by reducing the noise between > different OSs, but we should use it! :-) Cheers, Alistair
