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