Current Working Directory (Re: [squeak-dev] Re: [Vm-dev] new Cog VMs
yoshiki at vpri.org
Mon Oct 3 17:14:28 UTC 2011
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
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'.
More information about the Vm-dev