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