Bug #34972 [Com]: STDIN won't allow nonblocking.

2011-07-13 Thread Dygear at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=34972&edit=1

 ID: 34972
 Comment by: Dygear at gmail dot com
 Reported by:VJTD3 at VJTD3 dot com
 Summary:STDIN won't allow nonblocking.
 Status: Assigned
 Type:   Bug
 Package:Streams related
 Operating System:   win32 only
 PHP Version:5.2CVS-2008-07-15
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Yeah, I second the placing of a bounty on this problem, I'd also be more then 
willing to chip in to have this thing fixed as this still effects the 
usefulness 
of my software on the daily basis.


Previous Comments:

[2011-07-14 02:22:02] jchan at icebrg dot us

Please fix this. Interactive console applications written in PHP are impossible 
without a committed fix for this SIX YEARS old bug!

I use PHP for consistency across development environments, but this bug is 
making 
it impossible.

If a bounty can be placed, I'd like to place one! (Please show me a form)

Thanks!


[2011-07-13 21:20:18] hans+php at hansdude dot com

I have a use case affected by this bug that others do not mention: parallel 
processing.

There is no way to spawn a bunch of processes and babysit them until they're 
done while still capturing output.

While the previous comment makes valid points, I hope someone will still try to 
find a solution to this.


[2011-05-14 02:06:50] dewi at dewimorgan dot com

As I understand it (and some or all of this post may be wrong: please 
correct!), this is a platform limitation, since stuff like Windows' 
SetCommTimeouts() doesn't work for the stdin handle. I believe that this is 
because of the way pipes are handled under Windows, which makes them line-based 
rather than character-based. 

Any true "fix" (rather than just editing the docs) is a Hard Problem, since PHP 
has no control over Windows pipes.

The windows PHP port could internally do something nasty like:
if (ftell(STDIN) === 0) {
  // STDIN is the real STDIN, from a file or piped command.
}
else {
  // STDIN is a faked STDIN, built from keypresses.
}

This would fix the issue for those wanting interactive input, but the issue 
would still show up for pipes that aren't line separated:
ReplayKeyboardInput.exe | myScript.php

And even ignoring pipes, faking STDIN isn't trivial, either, but would probably 
involve a call to PeekConsoleInput().

I'm pretty sure if someone has some magic way for the receiving end of a pipe 
to make the pipe behave in a character-based way under Windows, then they'd 
happily implement it.

I'm considerably less convinced that they'd be willing to muddy PHP with a 
STDIN kludge that wouldn't work in some cases.

The NEED most people are expressing here is the need for interactive console 
input, via nonblocking keyboard reads, rather than the need for character-based 
pipes.

So, a "more correct" option would likely to be getting the ncurses extension 
working under Windows - the one platform that really needs it, and doesn't have 
it :) The public domain pdcurses.sourceforge.net may be useful here.

Workarounds:

As a workaround for PHP programmers on windows in the meantime, an external 
program that reads a single keypress can be used.

For people who don't mind blocking, this should work:
$KeyPressed = `perl -e "use Term::ReadKey;ReadMode 'cbreak'; print(ReadKey(0)); 
ReadMode 'normal';"`

To get nonblocking behaviour, where you can just read pending keystrokes, you'd 
need to launch that in a separate process, give it focus, and get it to send 
the characters to PHP whenever it read a character, and get your php file to 
poll the same file/socket for changes. 

If you don't have perl installed, a similar external program could likely be 
written in PowerShell, running as root and using $host.ui.rawui.KeyAvailable a 
WMI listener - but that's a crazy hoop to have to leap through.

Unless you have a really pressing need to write your app in PHP, then, odds 
are, it's easier to just write your script in a language which has functions 
for reading the keyboard directly (Perl, PowerShell, Python, AutoHotKey...). Or 
write a php readkey extension that launches a keyboard monitor in a separate 
thread or something, with start, stop, and flush functions for that key buffer.


[2011-01-01 10:48:41] paj...@php.net

@support at aculane dot com

what makes you think that anything has been done about this feature request?


[PHP-BUG] Bug #60309 [NEW]: fread(STDIN, 1024) returns instantly.

2011-11-15 Thread Dygear at gmail dot com
From: 
Operating system: Windows 7 - CLI
PHP version:  5.4.0RC1
Package:  Streams related
Bug Type: Bug
Bug description:fread(STDIN, 1024) returns instantly.

Description:

I am using the windows version of PHP 5.4 (5.4.0RC1) from 2011-Nov-10
19:52:12, 
VC9 x86 Non Thread Safe. In 5.3.x the code worked to where I could query a
client 
for an input from the command line using fread and STDIN. In the version
stated, 
5.4.0RC1, the function returns right away, and does not give the user
anytime to 
input a string.

Test script:
---


Expected result:

I would expect for there be an opportunity for the user to input a string.

Actual result:
--
The script has no result, and the client is never queried for a string.

-- 
Edit bug report at https://bugs.php.net/bug.php?id=60309&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60309&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60309&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60309&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60309&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60309&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60309&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60309&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60309&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60309&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60309&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60309&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60309&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60309&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60309&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60309&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60309&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60309&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60309&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60309&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60309&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60309&r=mysqlcfg



Bug #60309 [Com]: fread(STDIN, 1024) returns instantly.

2011-11-17 Thread Dygear at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60309&edit=1

 ID: 60309
 Comment by: Dygear at gmail dot com
 Reported by:Dygear at gmail dot com
 Summary:fread(STDIN, 1024) returns instantly.
 Status: Feedback
 Type:   Bug
 Package:Streams related
 Operating System:   Windows 7 - CLI
 PHP Version:5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

It seem that the snapshot was never compiled for the windows side, all 5.4 
branch 
downloads on the http://windows.php.net/snapshots/ are 0 Bytes, and just 
redirect 
in a loop.


Previous Comments:

[2011-11-16 07:41:20] larue...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

I can't reproduce this in my environ. 
but I do fine that 
stream_set_blocking(STDIN, FALSE);  Has no effect on windows


[2011-11-15 19:56:45] Dygear at gmail dot com

Description:

I am using the windows version of PHP 5.4 (5.4.0RC1) from 2011-Nov-10 19:52:12, 
VC9 x86 Non Thread Safe. In 5.3.x the code worked to where I could query a 
client 
for an input from the command line using fread and STDIN. In the version 
stated, 
5.4.0RC1, the function returns right away, and does not give the user anytime 
to 
input a string.

Test script:
---


Expected result:

I would expect for there be an opportunity for the user to input a string.

Actual result:
--
The script has no result, and the client is never queried for a string.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60309&edit=1


Bug #60309 [Com]: fread(STDIN, 1024) returns instantly.

2011-11-17 Thread Dygear at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60309&edit=1

 ID: 60309
 Comment by: Dygear at gmail dot com
 Reported by:Dygear at gmail dot com
 Summary:fread(STDIN, 1024) returns instantly.
 Status: Feedback
 Type:   Bug
 Package:Streams related
 Operating System:   Windows 7 - CLI
 PHP Version:5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

Never mind, I now realize that the link was at the bottom. So I downloaded 
http://windows.php.net/downloads/snaps/php-trunk/r319151/php-trunk-nts-windows-
vc9-x86-r319151.zip and now it works! Great job if that build includes your fix!


Previous Comments:

[2011-11-17 13:19:35] Dygear at gmail dot com

It seem that the snapshot was never compiled for the windows side, all 5.4 
branch 
downloads on the http://windows.php.net/snapshots/ are 0 Bytes, and just 
redirect 
in a loop.


[2011-11-16 07:41:20] larue...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

I can't reproduce this in my environ. 
but I do fine that 
stream_set_blocking(STDIN, FALSE);  Has no effect on windows


[2011-11-15 19:56:45] Dygear at gmail dot com

Description:

I am using the windows version of PHP 5.4 (5.4.0RC1) from 2011-Nov-10 19:52:12, 
VC9 x86 Non Thread Safe. In 5.3.x the code worked to where I could query a 
client 
for an input from the command line using fread and STDIN. In the version 
stated, 
5.4.0RC1, the function returns right away, and does not give the user anytime 
to 
input a string.

Test script:
---


Expected result:

I would expect for there be an opportunity for the user to input a string.

Actual result:
--
The script has no result, and the client is never queried for a string.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60309&edit=1