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 .
I also tried p :=(PipeableOSProcess command: 'ls') . p output. and it just returns an empty string. On Thu, Nov 5, 2015 at 11:50 PM Dimitris Chloupis <kilon.alios@gmail.com> 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 .
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
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. Are there other ways to return the output of the terminal ? On Fri, Nov 6, 2015 at 1:57 AM David T. Lewis <lewis@mail.msen.com> 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
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 <lewis@mail.msen.com> 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 what you want to do is: p := (PipeableOSProcess waitForCommand: 'ls'). p output. There's more information at http://pharo.gemtalksystems.com/book/PharoTools/OSProcess/ On Thu, Nov 5, 2015 at 7:25 PM, David T. Lewis <lewis@mail.msen.com> wrote:
On Thu, Nov 05, 2015 at 10:22:31PM -0500, David T. Lewis wrote:
Or put "(Delay forSeconds: 1)" right before you do "p output"?
Sorry, I meant to say:
"(Delay forSeconds: 1) wait" right before you do "p output"?
Dave
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 <lewis@mail.msen.com> 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 <lewis@mail.msen.com>
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
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 <kilon.alios@gmail.com> 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 <lewis@mail.msen.com> 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 <lewis@mail.msen.com>
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 <jpfersich@gmail.com> 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 <kilon.alios@gmail.com> 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 <lewis@mail.msen.com> 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 <lewis@mail.msen.com>
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 <kilon.alios@gmail.com> 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 <jpfersich@gmail.com> 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 <kilon.alios@gmail.com
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 <lewis@mail.msen.com> 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 <lewis@mail.msen.com>
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
additionally if inspect output a second time , the stdout string is gone, so maybe it flushes / deletes it ? is this normal ? On Fri, Nov 6, 2015 at 11:30 AM Dimitris Chloupis <kilon.alios@gmail.com> 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 <kilon.alios@gmail.com> 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 <jpfersich@gmail.com> 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 < kilon.alios@gmail.com> 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 <lewis@mail.msen.com> 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 <lewis@mail.msen.com>
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
Yes, that is normal. You are reading the output stream, and after it has been read (up to EOF) it will be empty. Glad it is working for you now :-) Dave
additionally if inspect output a second time , the stdout string is gone, so maybe it flushes / deletes it ? is this normal ?
On Fri, Nov 6, 2015 at 11:30 AM Dimitris Chloupis <kilon.alios@gmail.com> 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 <kilon.alios@gmail.com> 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 <jpfersich@gmail.com> 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 < kilon.alios@gmail.com> 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 <lewis@mail.msen.com> 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
<lewis@mail.msen.com> 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 <kilon.alios@gmail.com> 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 <kilon.alios@gmail.com> 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 <jpfersich@gmail.com> 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 <kilon.alios@gmail.com> 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 <lewis@mail.msen.com> 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 <lewis@mail.msen.com> 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
done https://pharo.fogbugz.com/f/cases/16944/OSProcess-stdout-is-not-returned-bac... On Sat, Nov 7, 2015 at 8:13 AM John Pfersich <jpfersich@gmail.com> wrote:
- 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 <kilon.alios@gmail.com> 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 <kilon.alios@gmail.com> 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 <jpfersich@gmail.com> 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 < kilon.alios@gmail.com> 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 <lewis@mail.msen.com> 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 <lewis@mail.msen.com>
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
participants (4)
-
David T. Lewis -
Dimitris Chloupis -
John Pfersich -
john pfersich