ok, that does it! [EMAIL PROTECTED] a lot! sorry first of all for my adding to the confusion when i jumped to comment on that ``-u`` option thing---of course, **no -u option** means **buffered**, positively, so there is buffering and buffering problems, **with -u option** there is **no buffer**, so also no buffering problems at that point. these add-option-to-switch-off things do get confusing sometimes.
ok, so the ``#!/usr/local/bin/python -u`` does work. as noted on http://www.imladris.com/Scripts/PythonForWindows.html: "Trying to run python cgi scripts in the (default) buffered mode will either result in a complete lack of return value from your cgi script (manifesting as a blank html page) or a "premature end of script headers" error." funny you don't get to see a lot of ``-u`` shebang lines these days tho. as the document goes on to explain, there is a way to put :: SetEnv PYTHONUNBUFFERED 1 into your apache ``httpd.conf``. this works for me! great! now, thinking about this problem it strikes me it has never bitten me before, where it should have. is there something special about the way web.py cgi apps work that make this thing pop up? also, in theory, since apache itself (as of v1.3) does no buffering of cgi output, then when apache calls a cgi process, and that process happily buffers at its own descretion, and then finalizes and terminates, then should the remaining buffer not be output and sent to apache---as happens with a script run from the command line? you do get to see all the output in that case, at long last upon process termination, right? i'm wondering. _wolf -- http://mail.python.org/mailman/listinfo/python-list
