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