Current Working Directory (Re: [squeak-dev] Re: [Vm-dev] new Cog VMs available...)

Yoshiki Ohshima yoshiki at
Mon Oct 3 17:14:28 UTC 2011

  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:
> > > 
> > >
> > > 
> > > 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:
> > 
> >
> >
> > 
> > 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,
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

  In my code, I already made a change so that instead of using
#command:, I now call
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

More information about the Vm-dev mailing list