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.al...@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.al...@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 <jpfers...@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.al...@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 <le...@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 >>>>>> <le...@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 >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> >>>>>> >>>> >
