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

Bert Freudenberg bert at
Mon Oct 3 17:18:59 UTC 2011

On 03.10.2011, at 19:14, Yoshiki Ohshima wrote:

>  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
> 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.

I don't see the problem. Just give it an absolute path to the executable. You already know that the binary is in your image folder. cwd is pretty much irrelevant for that, no?

- Bert -

More information about the Squeak-dev mailing list