On Fri, Jun 30, 2017 at 4:12 PM, Guillermo Polito <guillermopol...@gmail.com
> 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).
>
> 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?
>

I feel the analogy is that the VM is like WinWord.exe and the Image is like
a document.  The working directory would never be where WinWord.exe is
located.  Its where the document was opened from.

cheers -ben



> 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.
>
>  -  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
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> 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 <+33%206%2052%2070%2066%2013>
>

Reply via email to