Description:
------------
 According to the manual/docs, fgets/fread or any of these functions that specify a 'length in bytes' to be read will return after 'length bytes' have been read, newline, or EOF.
This is not true when reading from STDIN; newline is the only reason that these functions will return. 

Reproduce code:
---------------
<?php
$handle = fopen("php://stdin", "r");
if($handle)
{
   $buffer = fgets($handle, 11);
   echo $buffer;
}
fclose($handle);
?>

or for ST??? constants:

<?php
$buffer = fgets(STDIN, 11);
echo $buffer;
?>



Expected result:
----------------
  In either case I would expect 10 (length - 1) characters to be read from STDIN at which point fgets/fread would return and populate $buffer.

If I type: Won't work darnit!

I expect the script to terminate (fgets returns) after I type: Won't work (which is 10 characters) and to see: Won't work output to the screen.


Actual result:
--------------
  What happens is <RETURN> must be pressed before the functions return. The functions do return length-1 bytes at this point (but more than length characters can be typed).

If I type: Won't work darnit! then I see (as I type) onscreen: Won't work darnit! and now must press <RETURN>.
Won't work is now output to the screen (10 characters).

  The problem is that it is not consistant with the documentation (which reads these functions will return when length-1 bytes have been read). This really makes it very difficult to write CLI based scripts. I know there is ncurses but i'm sure that many of us are not into compiling on Win32. Also this relates to some of the stream functions that seem to only work on unix but are not documented as such. Many hours have been wasted searching for answers. I know this is similar bug report but I feel at least the documentation should be fixed if not PHP and maybe an explanation as to why it can't/won't be fixed would be nice.

Thank you