ID: 21891
User updated by: hz11 at nyu dot edu
Reported By: hz11 at nyu dot edu
Status: Wont fix
Bug Type: Feature/Change Request
Operating System: FreeBSD/Linux
PHP Version: 4.3.0
New Comment:
How would it break existing scripts? Firstly, CLI scripts aren't that
common yet, and especially those that rely on this type of behavior.
Secondly, what if it was a config setting, available only when running
as a CLI (akin to argv/argc). When working with scripts on the console
for interactive programs, or using a CLI script to generate raw XML for
instance, this type of newline mangle makes no sense and is cause for
very hackish scripts.
Previous Comments:
------------------------------------------------------------------------
[2004-03-08 12:03:42] [EMAIL PROTECTED]
Can not be fixed, as it breaks existing scripts.
------------------------------------------------------------------------
[2004-03-08 11:29:38] hz11 at nyu dot edu
I agree. Now that the CLI interface has matured it's in fairly
widespread use. I use CLI continually and this "feature" is a royal
pain. Perhaps when running in CLI mode this behavior could be
automatically disabled... this would be a much appreciated change.
Or, a special tag as suggested:
<?+
<?-
I would think putting something like this into PHP 5 wouldn't disrupt
things.
------------------------------------------------------------------------
[2004-02-20 02:41:33] threedee32 at rogers dot com
I think it would be useful to have the option to negate this feature,
perhaps with a modified end tag (\?> or something?). That way it would
still be backwards-compatible.
------------------------------------------------------------------------
[2003-05-20 15:34:06] csnyder at chxo dot com
"Included files shouldn't even contain a closing tag, for these exact
reasons."
This is excellent advice, but it is *not* a documented practice. All of
the examples in the Basic Syntax documentation include closing tags.
In fact, the documentation for include() says:
"... any code inside the target file which should be executed as PHP
code must be enclosed within valid PHP start and end tags."
I agree wholeheartedly that both the documentation and the behavior
should be changed, but to do so is to risk breaking a lot of existing
code.
------------------------------------------------------------------------
[2003-05-07 08:30:43] hz11 at nyu dot edu
I very much would like this reconsidered, for a number of reasons,
including documentation and functionality.
Granted, the documentation does say "will include," but in combination
with other statements it's simply not clear. If this behavior is vital
that it must remain, perhaps another look at this would avoid others
opening bug reports.
More importantly, however, is the fact that this behavior occurs at
all. Yes, PHP is primarily a web scripting language, but even in this
vein of usage, there's no reason for this.
First, included files generally don't contain trailing newlines. For
example, in your text editor of choice, going to the end of the
document, placing the cursor directly after ?> and deleting everything
to the right, you will not end up with any trailing newlines. So, is
this behavior in place to simply allow one newline, but not more than
one? Simply, there either is a character after the closing tag, or
there isn't.
Secondly, and most importantly, is that this shouldn't even be an
issue. Included files shouldn't even contain a closing tag, for these
exact reasons. PHP will end parsing at an end-of-file and placing a
closing tag will only cause problems with header() calls, etc. as
pointed out.
Lastly, if this behavior is vital enough to keep, I hope that a
consideration for CLI usage can be made. Ambigously keeping a newline
after a closing tag makes even less sense on the console. At the very
least, if PHP is compiled as a CLI, can this behavior can be
eliminated?
Thank you,
Hans
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/21891
--
Edit this bug report at http://bugs.php.net/?id=21891&edit=1
