I guess you are enabling zlib.output_compression.
If you are not, please change Status to "Open".
Thank you.

I can't change the status to 'Open', but I can say zlib.output_compression is off.

I tried leaving output_buffering = 4096 in php.ini and turning on implicit_flush in php.ini, and it's still not flushing my echo lines till the end of script execution, so neither the function or the ini config are working for me. If I make output_buffering = 0, it flushes correctly as expected, but as I understand it, the whole point of ob_implicit_flush() in runtime is to override the default ini config which is what I want to do.

Don't worray, it's known issue.
I can make it flush when all output buffers registered may be flushed, otherwise it just does not work.

Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work.

If you need to flush, do not use output buffers at all.

Note: Older PHP is just deleted the last output buffer registered with ob_implicit_flush. This is wrong behavior.

> If you need to flush, do not use output buffers at all.

That's what I'm trying to do, use ob_implicit_flush() at the beginning of my script to turn off ob.

> Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work.

I'm not wanting to change encoding or turn zlib compression on/off the middle of a script. I just have a basic 400 line script I'd like to output. I simply don't want to have ob turned on.

Sorry, but the bug system is not the appropriate forum for asking
support questions. Your problem does not imply a bug in PHP itself.
For a list of more appropriate places to ask for help using PHP,
please visit http://www.php.net/support.php

Thank you for your interest in PHP.

if you are not using ob and do not have gzip compression enabled, then by simply doing flush(); you'll get the data your are outputing sent to screen without any output buffering. 

iliaa, I appreciate you trying to point me to help, but I still think I'm right about this bug report. I've tried it on several machines with each stable version of PHP since the report. Now still with 4.2.3 I'm seeing the same thing. Again, I'm not using zlib output compression cause I let mod_gzip do that in apache. This is for a php shell script.

As you said, flush would send the output, but according to the documentation, ob_implicit_flush() should "result in a flush operation after every output call, so that explicit calls to flush() will no longer be needed".

I'm saying ob_implicit_flush is broken in 4.2.x and does not call flush() after each echo, or if it does, it's still not outputting to STDOUT.

By default, php.ini has 4k of output buffering. I want to leave that for the rest of the applications I'm running and since you can't modify the ini value with ini_set(), I'm resorting to the ob_* functions. Instead of calling ob_end_flush() at the start of the script cause according to the docs on that, as part of its functionality, it turns off ob.

Either way, I'm getting output buffering turned off while leaving 4k buffering in php.ini, but I doesn't mean that ob_implicit_flush() might still be not working right. I guess I'll just wait a few more days for 4.3.0 and try that out.

You can solve your problem by putting @ob_end_flush(); on top of your command line scripts.

It is easy to make it actually flush output. Difficult part is make it work always.

Some output buffers shouldn't be deleted and cannot be deleted. i.e. Some browsers will freeze if server send malformed compressed output. Thus ob_end_flush() wouldn't and shouldn't work in some cases. If it works, it's a bug should be fixed.

Fix is simple, but you have to live with that.
If you are interested, search php-dev archive.

BTW, ob_implicit_flush() simply enable SAPI level auto flushing even if its name imply PHP output buffer flushing. Don't blame me, I'm for fixing it ;)

Should have been won't fix

Now I'm getting a PHP notice in Windows XP using PHP 4.3.0 from the cmd line.

PHP Notice: ob_end_flush() [<a href='http://www.php.net/ref.outcontrol'>ref.outcontrol</a>]: failed to delete buffer default output handler. in C:\Apache\cgi-bin\mybot.php on line 58

In previous versions, ob_end_flush was my workaround to ob_implicit_flush not working. In 4.3.0 ob_end_flush isn't working for me and it does work in 4.2.3. Could someone make at least one of the two work again instead of keeping the "Won't fix" status?

Since current output buffer is statelss even if some buffers need stateful handling to prevent crashes/malformed output/ etc.

Don't start buffer if you don't need it. Complain people who insisted this behavior. Search php-dev archive ;)

And don't forget that some buffers should never be deleted once it's started. The error message is raised, since some users don't know it shouldn't.

We don't seem to be communicating very well. I've been wanting to shut off buffering this whole time. Your suggestion to not buffer if I don't need it is just telling me what I already want to do. I've been trying to use the functions documented in the manual that are supposed to shut it off, but they have a big "Won't fix" label on them in the bug database.

How about if I word it differently. I want the default buffer handling set in php.ini for my webpage output, but I don't want buffers for my command line scripts. I want those to output something to STDOUT as soon as it comes to a echo/print. If I don't use ob_end_flush, ob_implicit_flush, or ini_set, then what should I use to turn off buffering in my command line scripts.

As of PHP 4.3.0 you can use an alternative php.ini named:
php-{sapi}.ini, where {sapi} is the name of the sapi you are using.
So, for the cli, php will look for php-cli.ini before it tries php.ini.
For cgi it will look for php-cgi.ini etc.