At 13:56 18-11-2002, Derick Rethans wrote:
On Mon, 18 Nov 2002, Melvyn Sopacua wrote:Refrase with 'one of the people, who has ftp-access to the site, to update parts
> At 11:39 18-11-2002, Derick Rethans wrote:
>
> [...]
>
> > > Or a more general command to verify PHP code
> > > php_valid($code_str). That way the people who expect parse errors in
> > > their include files can do
> > >
> > > $code_str(implode("", file("include.inc")));
> > > if (php_valid($code_str)) {
> > > include_once("include.inc");
> > > }
> >
> >That would be hard, as the zend_compile function which runs the parse
> >also adds the functions, so if the code parses it includes it right
> >away. Again, for this one we _could_ not abort the script, but in the
> >case of include files I'd like to see it die hard again. eval() is
> >something different in a logical way, but the implementation in the zend
> >engine is about the same.
>
>
> Since there is '-l'int in the cli, how about a lint function? At least then,
> you can verify includes before including them and take any action you want,
> including mail().
>
> In a well designed application, you would be able to act on any parse error,
> but the 'main' file. Of course this won't work with 'require'.
IMO parse errors should just kill your script. It's IMO not up to the
language to provide fall back mechanisms for this. If a user too stupid
to use broken files it's their problem.
of the HTML'.
Secondly - a parse error is not by definition a 'stupid user' mistake. It can also
be, because 'short_open_tags' was switched off. It can also be, because in transit
via FTP the connection died. Or a hickup in the filesystem.
I'd rather have "Please wait while we fix this" than a half-baked site, or worse -
a queue of people reloading because nothing shows up.
With kind regards,
Melvyn Sopacua
<?php include("not_reflecting_employers_views.txt"); ?>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
