[squeak-dev] Raspberry PI & omxplayer from Squeak

David T. Lewis lewis at mail.msen.com
Thu Nov 19 04:08:54 UTC 2015


On Wed, Nov 18, 2015 at 06:36:10PM -0800, Eliot Miranda wrote:
> Hi Jon,
> 
>    The
> primitive primForkExec:stdIn:stdOut:stdErr:argBuf:argOffsets:envBuf:envOffsets:workingDir:
> directly calls execute, so if you invoke it with the name of the program it
> will fork and exec that program and answer its pid.  Not sure where the
> substitution of the shell is.  Is omxplayer perhaps a shell script that
> wraps the actual program?
> 
> I suggest you step though execution from your launch command all the way to
> the send of
> primForkExec:stdIn:stdOut:stdErr:argBuf:argOffsets:envBuf:envOffsets:workingDir:
> and see what its being invoked with, and you check what the omxplayer file
> is in the rip filesystem.
> 
> (I could be completely confused but
> see UnixOSProcessPlugin>>#forkAndExecInDirectory: in the
> VMConstruction-Plugins-OSProcessPlugin package at
> http://www.squeaksource.com/OSProcessPlugin and I think you'll agree with
> me that the primitive does not interpose a shell).

Exactly right. The interposed shell is something that I added as a
convenience for some OSProcess class side methods. With the benefit of
hindsight, I never should have done that. I makes it look as though you
are running the program that you intended to run, but the actual process
proxy available in the image is just a proxy on /bin/sh, which is totally
useless.

The more useful classes that let the image interact directly with an
external process are in package CommandShell. CommandShell was originally
part of package OSProcess, and I split it out because I thought at the
time that modularity was a good thing. I still think that modularity is
a good thing, but ... well, it does have its down side ;-)

Dave



More information about the Squeak-dev mailing list