this pinged my memory about OSX ... the funkiness is that you had to
arrange for PWD to be set "correctly" when double clicking an
application ... when running from the command line PWD was set
"correctly" ...
This was affecting GemStone because I was using the PWD of the client in
certain circumstances (and years ago) ...
Sounds like this quirk probably doesn't apply, but I still think it is
something to be aware of ...
Dale
On 3/21/16 11:13 AM, Mariano Martinez Peck wrote:
Hi guys,
In a couple of recent threads, there were discussions
about FileSystem >> #workingDirectory VS VM process getcwd(3) and
the fact that they do not match.
The current state is as follows:
1) *If Pharo was launched from double click* then we do not care about
its location and I think it's correct to default to image location:
1.1) FileSystem >> #workingDirectory refers to the directory
containing the .image file
1.2) The VM process getcmd() is the default one of the particular OS
($HOME in my OSX).
So...there is a mismatch between #workingDirectory and VM's process cmd.
*I think (as Damien said), that we should do a chdir() for the VM
process to match the .image location. *
2) *If Pharo was launched from command line* then we likely are
interested in the current CMD from where we launched the VM
process (imagine using Pharo for scripting). The current status is:
2.1) FileSystem >> #workingDirectory still refers to the directory
containing the .image file which I think it is incorrect.
2.2) The CMD of the VM process is correct. But again, there is a
mismatch with #workingDirectory.
*For this case, I think we should set FileSystem >> #workingDirectory
to CMD. *
Before start discussing how to implement this, do you agree with the idea?
Thanks in advance,
--
Mariano
http://marianopeck.wordpress.com
