Trying to understand OSProcess on MacOS Yosemite

So I try to understand how OSProcess work exactly to find why filetree seems not able to use it and generating the error I already reported earlier.

Using something simple like

OSProcess command:'pwd'

works great , I have the terminal open and I can see the correct return value of the command in my terminal but for some reason I can find no such info when I inspect the above example. So how exactly OSProcess returns the output of the terminal ? Is there an instance variable of some sort ? Because I tried to inspect it deeply and I found nothing . Can you help me understand how OSProcess work ? Because If I do understand it then I can find what the problem is .

On Thu, Nov 05, 2015 at 09:50:29PM +0000, Dimitris Chloupis wrote:
> So I try to understand how OSProcess work exactly to find why filetree
> seems not able to use it and generating the error I already reported
> earlier.
>
> Using something simple like
>
> OSProcess command:'pwd'
>
> works great , I have the terminal open and I can see the correct return
> value of the command in my terminal but for some reason I can find no such
> info when I inspect the above example. So how exactly OSProcess returns the
> output of the terminal ? Is there an instance variable of some sort ?
> Because I tried to inspect it deeply and I found nothing . Can you help me
> understand how OSProcess work ? Because If I do understand it then I can
> find what the problem is .

Hi Dimitris,

The OSProcess and CommandShell packages provide a variety of ways to
create and interact with operating system processes. In the case of
"OSProcess command: 'pwd'" it is starting a new unix shell (/bin/sh, which
on most systems is the Bash shell). Once it starts the shell, it asks
the shell to evaluate the 'pwd' command. In this case, you would see the
output of that 'pwd' command appearing in the terminal window for your
Pharo VM process.

If you inspect the result of this, you should see an instance of
ExternalUnixOSProcess. This is a proxy that represents the operating
system process that was used to run /bin/sh. It should look something like
this:

an ExternalUnixOSProcess with pid 10703 on /bin/sh (complete, normal termination with status 0)

The exitStatus instance variable of the ExternaUnixProcess should be 0 in
this example, which means only that the shell ran successfully (It does not
tell you exit status of the 'pwd' command in this case, although there are
other ways to do that).

There are other classes, especially PipeableOSProcess and CommandShell,
that support higher level control of OS processes, with direct connection
of the stdin/stdout/stderr streams to your Smalltalk image. I expect that
filetree would be using these higher level abstractions.

I don't know if this helps with your problem but maybe it gives you some
ideas.

Dave

I tested what I posted on a fresh Pharo 4.0 image on OSX 10.10 (Yosemite) so it sounds like something's wrong in the trunk.

On Thu, Nov 5, 2015 at 10:38 PM, Dimitris Chloupis <[hidden email]> wrote:

It says I am using Cog 4.3.3

I also used the code of John pfersich

p :=(PipeableOSProcess waitForCommand: 'ls') .
p output.

and it still returns an empty string while the process is

"a PipeableOSProcess on an ExternalUnixOSProcess with pid 769 on /bin/sh (complete, normal termination with status 0)"

I tried debugging but it froze the image with a

UndefinedObject(Object)>>doesNotUnderstand: #stepToCallee

this happened inside BlockClosure >> newProcess at Processor terminateActive

When I execute the command it works fine because I can see the output in the terminal.

On Fri, Nov 6, 2015 at 5:23 AM David T. Lewis <[hidden email]> wrote:

On Fri, Nov 06, 2015 at 12:41:58AM +0000, Dimitris Chloupis wrote:
> hello David and thank you for your help and your detailed explanation.
>
> as I said I used
>
> p :=(PipeableOSProcess command: 'ls') . p output.
>
> and it just returns an empty string.

The way this should work is that p (an instance of PipeableOSProcess) should
answer its output up to EOF (end of file) on the stdout from the process.

Can you please try stepping through this slowly in a debugger, and see if
it works? Or put "(Delay forSeconds: 1)" right before you do "p output"?
I am guessing that there may be something about the OSProcessPlugin in your
VM that is causing EOF detection to fail, such that you just get an empty
string as output.

I do not have a Mac to test, so I am only guessing. It might also be a
bug in the OSProcess plugin, I'm not sure.

Just to help me identify what your are running, could you please evaluate
"OSProcess accessor osppModuleVersionString" and let me know what it says?
The current version would be '4.6.1' but other versions may be in circulation,
and that could affect EOF detection.

Thanks,
Dave


>
> Are there other ways to return the output of the terminal ?
>
> On Fri, Nov 6, 2015 at 1:57 AM David T. Lewis <[hidden email]> wrote:
>
> > On Thu, Nov 05, 2015 at 09:50:29PM +0000, Dimitris Chloupis wrote:
> > > So I try to understand how OSProcess work exactly to find why filetree
> > > seems not able to use it and generating the error I already reported
> > > earlier.
> > >
> > > Using something simple like
> > >
> > > OSProcess command:'pwd'
> > >
> > > works great , I have the terminal open and I can see the correct return
> > > value of the command in my terminal but for some reason I can find no
> > such
> > > info when I inspect the above example. So how exactly OSProcess returns
> > the
> > > output of the terminal ? Is there an instance variable of some sort ?
> > > Because I tried to inspect it deeply and I found nothing . Can you help
> > me
> > > understand how OSProcess work ? Because If I do understand it then I can
> > > find what the problem is .
> >
> > Hi Dimitris,
> >
> > The OSProcess and CommandShell packages provide a variety of ways to
> > create and interact with operating system processes. In the case of
> > "OSProcess command: 'pwd'" it is starting a new unix shell (/bin/sh, which
> > on most systems is the Bash shell). Once it starts the shell, it asks
> > the shell to evaluate the 'pwd' command. In this case, you would see the
> > output of that 'pwd' command appearing in the terminal window for your
> > Pharo VM process.
> >
> > If you inspect the result of this, you should see an instance of
> > ExternalUnixOSProcess. This is a proxy that represents the operating
> > system process that was used to run /bin/sh. It should look something like
> > this:
> >
> > an ExternalUnixOSProcess with pid 10703 on /bin/sh (complete, normal
> > termination with status 0)
> >
> > The exitStatus instance variable of the ExternaUnixProcess should be 0 in
> > this example, which means only that the shell ran successfully (It does not
> > tell you exit status of the 'pwd' command in this case, although there are
> > other ways to do that).
> >
> > There are other classes, especially PipeableOSProcess and CommandShell,
> > that support higher level control of OS processes, with direct connection
> > of the stdin/stdout/stderr streams to your Smalltalk image. I expect that
> > filetree would be using these higher level abstractions.
> >
> > I don't know if this helps with your problem but maybe it gives you some
> > ideas.
> >
> > Dave
> >
> >
> >

good to know I am not the only one with this problem :) so how may I help solving this problem ? 

On Fri, Nov 6, 2015 at 10:11 AM john pfersich <[hidden email]> wrote:

I tested what I posted on a fresh Pharo 4.0 image on OSX 10.10 (Yosemite) so it sounds like something's wrong in the trunk.

On Thu, Nov 5, 2015 at 10:38 PM, Dimitris Chloupis <[hidden email]> wrote:

It says I am using Cog 4.3.3

I also used the code of John pfersich

p :=(PipeableOSProcess waitForCommand: 'ls') .
p output.

and it still returns an empty string while the process is

"a PipeableOSProcess on an ExternalUnixOSProcess with pid 769 on /bin/sh (complete, normal termination with status 0)"

I tried debugging but it froze the image with a

UndefinedObject(Object)>>doesNotUnderstand: #stepToCallee

this happened inside BlockClosure >> newProcess at Processor terminateActive

When I execute the command it works fine because I can see the output in the terminal.

On Fri, Nov 6, 2015 at 5:23 AM David T. Lewis <[hidden email]> wrote:

On Fri, Nov 06, 2015 at 12:41:58AM +0000, Dimitris Chloupis wrote:
> hello David and thank you for your help and your detailed explanation.
>
> as I said I used
>
> p :=(PipeableOSProcess command: 'ls') . p output.
>
> and it just returns an empty string.

The way this should work is that p (an instance of PipeableOSProcess) should
answer its output up to EOF (end of file) on the stdout from the process.

Can you please try stepping through this slowly in a debugger, and see if
it works? Or put "(Delay forSeconds: 1)" right before you do "p output"?
I am guessing that there may be something about the OSProcessPlugin in your
VM that is causing EOF detection to fail, such that you just get an empty
string as output.

I do not have a Mac to test, so I am only guessing. It might also be a
bug in the OSProcess plugin, I'm not sure.

Just to help me identify what your are running, could you please evaluate
"OSProcess accessor osppModuleVersionString" and let me know what it says?
The current version would be '4.6.1' but other versions may be in circulation,
and that could affect EOF detection.

Thanks,
Dave


>
> Are there other ways to return the output of the terminal ?
>
> On Fri, Nov 6, 2015 at 1:57 AM David T. Lewis <[hidden email]> wrote:
>
> > On Thu, Nov 05, 2015 at 09:50:29PM +0000, Dimitris Chloupis wrote:
> > > So I try to understand how OSProcess work exactly to find why filetree
> > > seems not able to use it and generating the error I already reported
> > > earlier.
> > >
> > > Using something simple like
> > >
> > > OSProcess command:'pwd'
> > >
> > > works great , I have the terminal open and I can see the correct return
> > > value of the command in my terminal but for some reason I can find no
> > such
> > > info when I inspect the above example. So how exactly OSProcess returns
> > the
> > > output of the terminal ? Is there an instance variable of some sort ?
> > > Because I tried to inspect it deeply and I found nothing . Can you help
> > me
> > > understand how OSProcess work ? Because If I do understand it then I can
> > > find what the problem is .
> >
> > Hi Dimitris,
> >
> > The OSProcess and CommandShell packages provide a variety of ways to
> > create and interact with operating system processes. In the case of
> > "OSProcess command: 'pwd'" it is starting a new unix shell (/bin/sh, which
> > on most systems is the Bash shell). Once it starts the shell, it asks
> > the shell to evaluate the 'pwd' command. In this case, you would see the
> > output of that 'pwd' command appearing in the terminal window for your
> > Pharo VM process.
> >
> > If you inspect the result of this, you should see an instance of
> > ExternalUnixOSProcess. This is a proxy that represents the operating
> > system process that was used to run /bin/sh. It should look something like
> > this:
> >
> > an ExternalUnixOSProcess with pid 10703 on /bin/sh (complete, normal
> > termination with status 0)
> >
> > The exitStatus instance variable of the ExternaUnixProcess should be 0 in
> > this example, which means only that the shell ran successfully (It does not
> > tell you exit status of the 'pwd' command in this case, although there are
> > other ways to do that).
> >
> > There are other classes, especially PipeableOSProcess and CommandShell,
> > that support higher level control of OS processes, with direct connection
> > of the stdin/stdout/stderr streams to your Smalltalk image. I expect that
> > filetree would be using these higher level abstractions.
> >
> > I don't know if this helps with your problem but maybe it gives you some
> > ideas.
> >
> > Dave
> >
> >
> >

looks like a vm problem after instruction of Thierry instead of

wget -O- get.pharo.org/50+vmLatest | bash

I did

wget -O- get.pharo.org/50+vm | bash

and now it works fine I can see the output with an inspection.

Looks like something changed in the vm that broke this.

On Fri, Nov 6, 2015 at 10:23 AM Dimitris Chloupis <[hidden email]> wrote:

good to know I am not the only one with this problem :) so how may I help solving this problem ? 

On Fri, Nov 6, 2015 at 10:11 AM john pfersich <[hidden email]> wrote:

I tested what I posted on a fresh Pharo 4.0 image on OSX 10.10 (Yosemite) so it sounds like something's wrong in the trunk.

On Thu, Nov 5, 2015 at 10:38 PM, Dimitris Chloupis <[hidden email]> wrote:

It says I am using Cog 4.3.3

I also used the code of John pfersich

p :=(PipeableOSProcess waitForCommand: 'ls') .
p output.

and it still returns an empty string while the process is

"a PipeableOSProcess on an ExternalUnixOSProcess with pid 769 on /bin/sh (complete, normal termination with status 0)"

I tried debugging but it froze the image with a

UndefinedObject(Object)>>doesNotUnderstand: #stepToCallee

this happened inside BlockClosure >> newProcess at Processor terminateActive

When I execute the command it works fine because I can see the output in the terminal.

On Fri, Nov 6, 2015 at 5:23 AM David T. Lewis <[hidden email]> wrote:

On Fri, Nov 06, 2015 at 12:41:58AM +0000, Dimitris Chloupis wrote:
> hello David and thank you for your help and your detailed explanation.
>
> as I said I used
>
> p :=(PipeableOSProcess command: 'ls') . p output.
>
> and it just returns an empty string.

The way this should work is that p (an instance of PipeableOSProcess) should
answer its output up to EOF (end of file) on the stdout from the process.

Can you please try stepping through this slowly in a debugger, and see if
it works? Or put "(Delay forSeconds: 1)" right before you do "p output"?
I am guessing that there may be something about the OSProcessPlugin in your
VM that is causing EOF detection to fail, such that you just get an empty
string as output.

I do not have a Mac to test, so I am only guessing. It might also be a
bug in the OSProcess plugin, I'm not sure.

Just to help me identify what your are running, could you please evaluate
"OSProcess accessor osppModuleVersionString" and let me know what it says?
The current version would be '4.6.1' but other versions may be in circulation,
and that could affect EOF detection.

Thanks,
Dave


>
> Are there other ways to return the output of the terminal ?
>
> On Fri, Nov 6, 2015 at 1:57 AM David T. Lewis <[hidden email]> wrote:
>
> > On Thu, Nov 05, 2015 at 09:50:29PM +0000, Dimitris Chloupis wrote:
> > > So I try to understand how OSProcess work exactly to find why filetree
> > > seems not able to use it and generating the error I already reported
> > > earlier.
> > >
> > > Using something simple like
> > >
> > > OSProcess command:'pwd'
> > >
> > > works great , I have the terminal open and I can see the correct return
> > > value of the command in my terminal but for some reason I can find no
> > such
> > > info when I inspect the above example. So how exactly OSProcess returns
> > the
> > > output of the terminal ? Is there an instance variable of some sort ?
> > > Because I tried to inspect it deeply and I found nothing . Can you help
> > me
> > > understand how OSProcess work ? Because If I do understand it then I can
> > > find what the problem is .
> >
> > Hi Dimitris,
> >
> > The OSProcess and CommandShell packages provide a variety of ways to
> > create and interact with operating system processes. In the case of
> > "OSProcess command: 'pwd'" it is starting a new unix shell (/bin/sh, which
> > on most systems is the Bash shell). Once it starts the shell, it asks
> > the shell to evaluate the 'pwd' command. In this case, you would see the
> > output of that 'pwd' command appearing in the terminal window for your
> > Pharo VM process.
> >
> > If you inspect the result of this, you should see an instance of
> > ExternalUnixOSProcess. This is a proxy that represents the operating
> > system process that was used to run /bin/sh. It should look something like
> > this:
> >
> > an ExternalUnixOSProcess with pid 10703 on /bin/sh (complete, normal
> > termination with status 0)
> >
> > The exitStatus instance variable of the ExternaUnixProcess should be 0 in
> > this example, which means only that the shell ran successfully (It does not
> > tell you exit status of the 'pwd' command in this case, although there are
> > other ways to do that).
> >
> > There are other classes, especially PipeableOSProcess and CommandShell,
> > that support higher level control of OS processes, with direct connection
> > of the stdin/stdout/stderr streams to your Smalltalk image. I expect that
> > filetree would be using these higher level abstractions.
> >
> > I don't know if this helps with your problem but maybe it gives you some
> > ideas.
> >
> > Dave
> >
> >
> >

• Can you open a bug entry on http://pharo.fogbugz.com? This worked in Pharo 4.0.

Sent from my iPad

On Nov 6, 2015, at 01:30, Dimitris Chloupis <[hidden email]> wrote:

looks like a vm problem after instruction of Thierry instead of

wget -O- get.pharo.org/50+vmLatest | bash

I did

wget -O- get.pharo.org/50+vm | bash

and now it works fine I can see the output with an inspection.

Looks like something changed in the vm that broke this.

On Fri, Nov 6, 2015 at 10:23 AM Dimitris Chloupis <[hidden email]> wrote:

good to know I am not the only one with this problem :) so how may I help solving this problem ? 

On Fri, Nov 6, 2015 at 10:11 AM john pfersich <[hidden email]> wrote:

I tested what I posted on a fresh Pharo 4.0 image on OSX 10.10 (Yosemite) so it sounds like something's wrong in the trunk.

On Thu, Nov 5, 2015 at 10:38 PM, Dimitris Chloupis <[hidden email]> wrote:

It says I am using Cog 4.3.3

I also used the code of John pfersich

p :=(PipeableOSProcess waitForCommand: 'ls') .
p output.

and it still returns an empty string while the process is

"a PipeableOSProcess on an ExternalUnixOSProcess with pid 769 on /bin/sh (complete, normal termination with status 0)"

I tried debugging but it froze the image with a

UndefinedObject(Object)>>doesNotUnderstand: #stepToCallee

this happened inside BlockClosure >> newProcess at Processor terminateActive

When I execute the command it works fine because I can see the output in the terminal.

On Fri, Nov 6, 2015 at 5:23 AM David T. Lewis <[hidden email]> wrote:

On Fri, Nov 06, 2015 at 12:41:58AM +0000, Dimitris Chloupis wrote:
> hello David and thank you for your help and your detailed explanation.
>
> as I said I used
>
> p :=(PipeableOSProcess command: 'ls') . p output.
>
> and it just returns an empty string.

The way this should work is that p (an instance of PipeableOSProcess) should
answer its output up to EOF (end of file) on the stdout from the process.

Can you please try stepping through this slowly in a debugger, and see if
it works? Or put "(Delay forSeconds: 1)" right before you do "p output"?
I am guessing that there may be something about the OSProcessPlugin in your
VM that is causing EOF detection to fail, such that you just get an empty
string as output.

I do not have a Mac to test, so I am only guessing. It might also be a
bug in the OSProcess plugin, I'm not sure.

Just to help me identify what your are running, could you please evaluate
"OSProcess accessor osppModuleVersionString" and let me know what it says?
The current version would be '4.6.1' but other versions may be in circulation,
and that could affect EOF detection.

Thanks,
Dave


>
> Are there other ways to return the output of the terminal ?
>
> On Fri, Nov 6, 2015 at 1:57 AM David T. Lewis <[hidden email]> wrote:
>
> > On Thu, Nov 05, 2015 at 09:50:29PM +0000, Dimitris Chloupis wrote:
> > > So I try to understand how OSProcess work exactly to find why filetree
> > > seems not able to use it and generating the error I already reported
> > > earlier.
> > >
> > > Using something simple like
> > >
> > > OSProcess command:'pwd'
> > >
> > > works great , I have the terminal open and I can see the correct return
> > > value of the command in my terminal but for some reason I can find no
> > such
> > > info when I inspect the above example. So how exactly OSProcess returns
> > the
> > > output of the terminal ? Is there an instance variable of some sort ?
> > > Because I tried to inspect it deeply and I found nothing . Can you help
> > me
> > > understand how OSProcess work ? Because If I do understand it then I can
> > > find what the problem is .
> >
> > Hi Dimitris,
> >
> > The OSProcess and CommandShell packages provide a variety of ways to
> > create and interact with operating system processes. In the case of
> > "OSProcess command: 'pwd'" it is starting a new unix shell (/bin/sh, which
> > on most systems is the Bash shell). Once it starts the shell, it asks
> > the shell to evaluate the 'pwd' command. In this case, you would see the
> > output of that 'pwd' command appearing in the terminal window for your
> > Pharo VM process.
> >
> > If you inspect the result of this, you should see an instance of
> > ExternalUnixOSProcess. This is a proxy that represents the operating
> > system process that was used to run /bin/sh. It should look something like
> > this:
> >
> > an ExternalUnixOSProcess with pid 10703 on /bin/sh (complete, normal
> > termination with status 0)
> >
> > The exitStatus instance variable of the ExternaUnixProcess should be 0 in
> > this example, which means only that the shell ran successfully (It does not
> > tell you exit status of the 'pwd' command in this case, although there are
> > other ways to do that).
> >
> > There are other classes, especially PipeableOSProcess and CommandShell,
> > that support higher level control of OS processes, with direct connection
> > of the stdin/stdout/stderr streams to your Smalltalk image. I expect that
> > filetree would be using these higher level abstractions.
> >
> > I don't know if this helps with your problem but maybe it gives you some
> > ideas.
> >
> > Dave
> >
> >
> >