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

Reply via email to