You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Alex P <st...@gmail.com> on 2014/05/01 02:58:37 UTC

Re: [exec] DefaultExecutor PumpStreamHandler and windows command prompt

So, after clean up, it looks like this:
https://github.com/sans17/basesix/blob/master/basesix/src/main/java/us/ligusan/utils/io/PumpStreamHandlerAlt.java

Regards,
   AlexP.


On Mon, Apr 28, 2014 at 5:06 PM, Alex P <st...@gmail.com> wrote:

> Siegfried,
>
> Had to write my own implementation, because PumpStreamHandler does not
> give access to streams.
> Not sure if it would have any use.
> Basically it does the same thing except that it continuously reads in
> run() (not forgetting graceful stop/close etc.).
> Something like:
> ----------------------
>     public void run()
>     {
>         try
>         {
>             for(int read = -1; (read = getInputStream().read()) >= 0;)
>                 getOutputStream().write(read);
>         }
>         catch(IOException e)
>         {}
>     }
> ----------------------
>
> 1) read() is the only reliable operation in InputStream;
> 2) StreamPumper is already a thread entirely dedicated to read operation -
> who cares if it is blocked.
>
> I can clean up my code and put it somewhere. Let me know.
>
> Regards,
>    AlexP.
>
>
> On Mon, Apr 28, 2014 at 11:38 AM, Siegfried Goeschl <sg...@gmx.at>wrote:
>
>> Hi Alex,
>>
>> interesting - do you mind sharing your code? I can at least update the
>> FAQ ...
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>
>> On 28.04.14 17:27, Alex P wrote:
>>
>>> I resolved the issue, but cannot use PumpStreamHandler - had to write my
>>> own.
>>>
>>> PumpStreamHandler implementation looks wrong to me now.
>>> 1) InputStreamPumper, what is used in case of System.in input waits for
>>> available() to return grater than 0, but it is not guarantied, and looks
>>> like in Windows it returns such only after <Enter> is pressed - that
>>> cased
>>> my original issue;
>>> 2) StreamPumper, what is used in other cases (for example if I wrap
>>> System.in in my own implementation) will read into buffer and therefore
>>> might wait until the whole buffer is filled in.
>>>
>>> Regards,
>>>     AlexP
>>>
>>>
>>> On Mon, Apr 28, 2014 at 4:15 AM, Siegfried Goeschl <sg...@gmx.at>
>>> wrote:
>>>
>>>  Hi Alexander,
>>>>
>>>> no idea but the OS behave a bit differently especially with Windows
>>>> stream
>>>> re-direction does not work perfectly
>>>>
>>>> Cheers,
>>>>
>>>> Siegfried Goeschl
>>>>
>>>> On 24.04.14 22:26, Alexander Prishchepov wrote:
>>>>
>>>>  Hello, All.
>>>>>
>>>>> I am starting new process with DefaultExecutor like that:
>>>>> ----------------------------------------------------------------------
>>>>>               DefaultExecutor executor = new DefaultExecutor();
>>>>>               executor.setStreamHandler(new
>>>>> PumpStreamHandler(System.out,
>>>>> System.err, System.in));
>>>>>               executor.execute(<some command line>);
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Everything works great, but somehow in windows command prompt input is
>>>>> not visible right away - only after <Enter> is pressed.
>>>>> Any idea, why that might happen?
>>>>>
>>>>> Tested it on unix (Solaris), and it does not happen - input is visible
>>>>> as
>>>>> I type.
>>>>>
>>>>> Regards,
>>>>>      AlexP
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: user-help@commons.apache.org
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>