Edit report at https://bugs.php.net/bug.php?id=41810&edit=1
ID: 41810
Updated by: ras...@php.net
Reported by: d dot albano at gmail dot com
Summary: Unable to catch Parse Errors
Status: Not a bug
Type: Feature/Change Request
Package: *General Issues
Operating System: Linux
PHP Version: 5.2.3
Block user comment: N
Private report: N
New Comment:
Even in the templating case there really is no excuse for pushing templates
with
parse errors to production. Running "php -l" as part of your pre-push testing
is
the expected bare minimum and hopefully you have actual tests you run with
decent
code coverage as well. You could also run it in your pre-commit hook in your
VCS.
Addressing this in PHP itself is extremely low-priority which means it will
likely never happen.
Previous Comments:
------------------------------------------------------------------------
[2012-10-05 20:52:43] airetamstrm at gmail dot com
Contrary to what others have said here, require/include_once do NOT (always)
happen at compile time.
Otherwise, it would be impossible to do this:
<?php
foreach(glob('/path/to/php/includes/*') as $match) {
if (is_dir($match)) {
foreach (glob($directory.'/*.php') as $filename) {
require_once(($filename);
}
} else if (is_file($match)) {
foreach (glob($directory.'/*.php') as $filename) {
require_once(($filename);
}
}
}
?>
I've found the best way to work around this problem is to use eval, which is a
poor
solution at best. There really should be a way to catch this, considering PHP
is
an
interpreted / templating language. Regardless of the intended functionality
/doc
of
require/include_once there absolutely should be some mechanism to do this. See
below for an
example on how to at least silence parse errors:
function safeInclude($filename) {
$fc = file_get_contents($filename);
eval('?>'.$fc);
}
However, in the defense of the developers, if you're checking code for errors
before
including it, you're one or more of the following:
1) Building convenience code to help with rapid development
2) Pulling in code that you don't fully trust from others that may be buggy
3) Doing silly, inexcusable things with production
4) Templating and thus #2
Fixing this bug likely be the most help to #1 and #4. If you're doing #4 you
need to fire
someone, if you're doing #3 you need to fire yourself. At the very least, if
you're trying
to do this you should review WHY you're trying to do this, and see if perhaps
there's
something else terribly wrong with your design approach.
I'm a #4 and would like it if someone could look at fixing this.
------------------------------------------------------------------------
[2012-09-15 21:45:32] ras...@php.net
This can't be done safely within the same parser instance as your main script.
You will need to create a separate instance, as in system("php -l $script"); to
do that check. I would suggest you do this once when these scripts are created
and move them into a "checked" directory or something so you don't do it on
every
include.
------------------------------------------------------------------------
[2012-09-15 20:53:11] james dot dobb at gmail dot com
I agree that this, perhaps not a bug but a missing feature needs to be
addressed,
There should be a secure way of including scripts from another script and be
able
to continue the calling script if an error occurs, the lack of functionality
here
is causing me a major headache.....
------------------------------------------------------------------------
[2010-07-02 13:41:24] paj...@php.net
It is not, please double read the manual about require/include_once.
------------------------------------------------------------------------
[2010-07-02 12:34:32] sneak at datavibe dot net
This classification is not bogus at all. Consider the following:
== main.php ==
<?php
$filename = sprintf("%s.php", 'myfile' );
include_once($filename);
?>
== myfile.php ==
<?php
syntax errors here !@#$%^&*()_
?>
The parsing of myfile.php must necessarily happen at main.php's RUNTIME,
because
the filename is not available until sprintf() is called.
This is a bug.
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=41810
--
Edit this bug report at https://bugs.php.net/bug.php?id=41810&edit=1
