Hi, Dave,

At Fri, 30 Sep 2011 23:47:16 -0400,
David T. Lewis wrote:
> 
> On Fri, Sep 30, 2011 at 03:27:44PM -0700, Yoshiki Ohshima wrote:
> > 
> > At Wed, 28 Sep 2011 13:47:22 -0700,
> > Eliot Miranda wrote:
> > > 
> > > ...at?http://www.mirandabanda.org/files/Cog/VM/VM.r2496/.
> > > 
> > > CogVM binaries as per VMMaker.oscog-eem.128/r2496
> > > Fix regression in object-as-method/cannot-interpret for single and polymorphic
> > > inline cache misses (lookup:for:methodAndErrorSelectorInto:).
> > > Fix formatting bugette in context printing.
> > > 
> > > This fixes a regression in objects-as-methods which Nicholas was suffering from as a crash during Run Coverage in the Test Runner.
> > 
> >   This probably is not an issue with the latest VM, and I now remember the
> > discussion related to my question here:
> > 
> > http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html
> > http://forum.world.st/Problems-with-Mac-VM-5-7-and-5-8-on-the-command-line-td3526363.html
> > 
> > but I'm not sure the current consensus is and let me ask it in the
> > context of my problem.
> > 
> > So, the switch apparently happened sometime after 'Croquet Closure Cog
> > VM [CoInterpreter VMMaker.oscog-eem.56] Croquet Cog 3.0.0', which I
> > have been using for a project.  When I try to switch to the latest 
> > version of VM, there are (at least) two things that has changed.
> > 
> > One is that
> > 
> > OSProcess thisOSProcess processAccessor primGetCurrentWorkingDirectory
> > 
> > now returns '/'.  I used to launch an external command by:
> > 
> > PipeableOSProcess command: './demo'.
> > 
> > it stopped working.  Is this just a known issue, and I should just
> > use longer interface to OSProcess with cwd explicitly specified?
> 
> I do not have a mac to test, but in case it may help:
> 
> The primGetCurrentWorkingDirectory method calls the C library function
> getcwd(), which answers the current working directory of the calling
> process (i.e. the process in which the VM is running). If the result
> is '/' then I suspect there is something about the way the VM is being
> launched that causes it to think it is running from the root directory,
> or perhaps a chroot() is being done.

  Yes, as quoted in
http://forum.world.st/working-directory-under-Mac-OS-X-td3550987.html,
running the VM at '/' was a conscious decision.  Sorry for not clearly
asking a question.  My question was that how people deal with this
change, when the change has apparent drawback in a case such as this.
(Say, you want to distribute your application as a single directory,
the natural place to put an external executable is somewhere under the
directory.  But now cwd is '/', you need to supply the current
directory.)

  In my code, I already made a change so that instead of using
#command:, I now call
#command:environment:workingDir:input:output:error:errorPipelineStream:.
from a convenience method.  Perhaps just having a variation of
#command: that invokes command in the image directory would be handy.

> Unix systems also usually have a shell variable $PWD that points to
> the current working directory. You can read its value with
> 'OSProcess thisOSProcess environmentAt: #PWD'. On my system (Linux)
> this gives the same result as primGetCurrentWorkingDirectory, but
> possibly it will give the result you need on OS X.

  $PWD is certainly the same as the VMs cwd (checked with lsof
command).  I get nil for environmentAt: #PWD.

> By the way, you can also call primGetCurrentWorkingDirectory with
> 'OSProcess thisOSProcess getCwd'.

  Ah, thanks!

-- Yoshiki