#21891 [Opn->Bgs]: Closing PHP tag and Newlines Revisted

ID: 21891 Updated by: goba@php.net Reported By: hz11 at nyu dot edu -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: FreeBSD/Linux PHP Version: 4.3.0 New Comment: IMHO the docs are not misleading. The doc says: "The closing tag for the block will include the immediately trailing newline if one is present." Note the words "will include". After this, the docs says (what you also quoted): "This works as expected, because when PHP hits the ?> closing tags, it simply starts outputting whatever it finds until it hits another opening tag." Which is perfectly OK, if you read again the text above. The closing ?> includes the trailing newline. So everything after the closing ?> is output (not including the trailing newline, as it is included in the closing tag itself). Why this makes sense? PHP is a web scripting language (or it is fucused on web scripting). Conside that you have an include file "common.inc", and it is closed with a PHP closing tag ?>. You include this file from some index.php expecting it to provide some defined functions, and output a header() in index.php before doing anything. You won't succeed in outputting the header() if the newline after the ?> closing tag is treated as output, as there would be some output, and then headers cannot be sent. This is the expected behaviour, it won't be changed I can assure you, and it is documented. The docs says "...the closing tag includes the newline..." and "...after the closing tag...", this implies that "...after the newline if it is present after ?>..." isn't it? Previous Comments: ------------------------------------------------------------------------ [2003-05-02 05:09:39] gk at proliberty dot com This is not a documentation problem; the documentation actually says TWICE that this should NOT be happening. Here's the second place: >This works as expected, because when PHP hits the ?> closing tags, it simply starts outputting whatever it finds until it hits another opening tag This bug involving LOSS OF DATA. That is serious IMHO; second only to crashes. I have reproduced this in PHP 4.3.2-RC (cli) (built: Apr 25 2003 18:03:38) and also in apache module. -- a simpler example script: line1 <?php ?> line2 -- output: line1 line2 ------------------------------------------------------------------------ [2003-01-26 14:39:00] hz11 at nyu dot edu This is a follow-up to bug #13954. I'm sorry to open another ticket for this, however I added some comments, yet didn't see any indication that they were saved (ie, I didn't get an email confirmation). I'd like another look at this issue, since the documentation seems to clash with actual behavior; plus, I think the actual behavior is peculiar. Using a CLI compiled 4.3.0 binary, this script: #!/bin/psh <?php $foo = 'Hello'; $bar = 'World'; ?> <?=$foo?> <?=$bar?> <?php echo 'DONE!'; ?> This script will produce: <empty line> HelloWorld DONE![unix prompt]$ Note that there is no trailing space (x20) after <?=$foo?> and <?=$bar?> - only a newline (x0A) According to http://www.php.net/manual/en/language.basic-syntax.php#language.basic-syntax.phpmode "The closing tag for the block will include the immediately trailing newline if one is present." Now if I add a x20 after the closing tag, then the newlines are honored. Why does this behavior make any sense? Adding the x20 after the closing tag is very hackish, especially since the aforementioned URL has statements like "...because when PHP hits the ?> closing tags, it simply starts outputting whatever it finds until it hits another opening tag" throughout. Obviously, however, this isn't true, since PHP decides to ignore the newline immediately after the closing tag. I don't understand why this behavior would be desired anyway; what is outside the PHP tags should simply be passed through. And especially since the docs are misleading about this. Thank you, and please don't hesitate to request clarification if I'm not making myself clear. Hans ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=21891&edit=1