[nycphp-talk] Installing PEAR in FreeBSD
Francisco Reyes
lists at natserv.com
Mon May 10 18:57:55 EDT 2004
On Fri, 7 May 2004, Hans Zaunere wrote:
> > Anyone has gotten PEAR installed in FreeBSD through the port system?
> > I am getting an error saying that PHP is already installed. I
> I've always done this by compiling from source, but maybe:
Have been considering that option.
> make reinstall
Will try.
> would help? Maybe even a:
> make deinstall
The pear port is never installed so that won't work.
It is also a problem in FreeBSD to install from Ports the mod_php and php
CLI ports at the same time. I think this is why Pear may be failing.
I am rebuilding my play box after a HD crash and I will experiment more
thene. Amongst the options I am considering so far is to install the CLI
on the play/test box and then make a tar of the files an copy them over to
the production box. Then manually change php.ini and anything else...
Although most likely my first option will be trying to install Pear by
manually and see if that is not too much work.
>From hans not junk at nyphp.com Mon May 10 21:19:16 2004
Return-Path: <hans not junk at nyphp.com>
Received: from ehost011-1.intermedia.net (unknown [64.78.21.3])
by virtu.nyphp.org (Postfix) with ESMTP id AED61A862D
for <talk at lists.nyphp.org>; Mon, 10 May 2004 21:19:16 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nycphp-talk] NEW PHundamentals Question - Error Handling
Date: Mon, 10 May 2004 18:19:12 -0700
Message-ID: <41EE526EC2D3C74286415780D3BA9F8701E444A3 at ehost011-1.exch011.intermedia.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nycphp-talk] NEW PHundamentals Question - Error Handling
Thread-Index: AcQ2mzPsT014oPTKTiOkn7Y+s9/0ygACmMnA
From: "Hans Zaunere" <hans not junk at nyphp.com>
To: "NYPHP Talk" <talk at lists.nyphp.org>
X-BeenThere: talk at lists.nyphp.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: NYPHP Talk <talk at lists.nyphp.org>
List-Id: NYPHP Talk <talk.lists.nyphp.org>
List-Unsubscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
<mailto:talk-request at lists.nyphp.org?subject=unsubscribe>
List-Archive: <http://lists.nyphp.org/pipermail/talk>
List-Post: <mailto:talk at lists.nyphp.org>
List-Help: <mailto:talk-request at lists.nyphp.org?subject=help>
List-Subscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
<mailto:talk-request at lists.nyphp.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2004 01:19:17 -0000
> The granddaddy class would be rather=20
> abstract. It would have member variables=20
> correlating to the five W's.
>=20
> The 'abstract' class would be extended to=20
> take care of more specific situations.
>=20
> But in general all the descendant classes would have=20
> inherited methods for dealing with felonies,=20
> misdemeanors, and ethical infractions and=20
> perhaps a method for granting immunity (especially=20
> on a 'quid pro quo' basis for more information=20
> leading to an indictment of other guilty routines)
> The methods would be just overloaded -- whoops,=20
> pardon me, I mean extended to deal with the specifics=20
> of each of the more specialized classes=20
> (and their environments).
I think it's much simpler; usually, over-abstraction is a bad thing.
The original PHundamentals seed was this:
"Something can always go wrong in an application so it is essential that
your application have an error handler. What types of errors can be=20
safely ignored, and which ones should be trapped by an error handler?=20
What is the best way to handle those errors?"
I think the always important distinction of development vs production is
again vital when talking about error handling.
The first rule of error handling, in my view is to be alerted of ALL
errors, notices, warnings, etc. As such, in php.ini I always have:
error_reporting =3D E_ALL
or if I can't modify my php.ini:
error_reporting(E_ALL);
is set in the top level include of my application. I do this for both
dev and production environments (it's often more important in dev). I
also ensure display_errors is off and log_errors is on. This is all
automatically set correctly if you use php.ini-recommended
By default, with log_errors set to on, errors go to the Apache error
logs. So:
tail -f /var/log/www/mydomain.com/error_log
(or whatever the path obviously)
will show all signs of errors, as they happen, without splashing errors
to the browser. Even in development, errors dumped to the browser are
bad because they can become hidden in the HTML.
So, the big question; what is safe to ignore? Basically, nothing. I
always code so that I never have any warnings about uninitialized
variables, which is a common error (actually, notice) to ignore. I
admit, there are times - like when repopulating form values on small
sites - when I will suppress an uninitialized variable using a @ if I'm
sure a NULL or 0 value will be handled correctly. It's good practice to
not throw any "sloppy" errors in your application, and under any states
of the page; this is "PHundamentally" good programming.
So what about "non-sloppy" errors; or those errors caused by an
exceptional or unexpected condition? For one, there are two sides to
this; what the user (browser) sees, and what the maintainer (developer)
sees. Always - *always* - show a generic error to the user. If the
database is offline, don't say "Our database is currently offline" but
rather "System under maintenance". If the system is about to crash and
PHP's core has become horribly corrupted: "System under maintenance"
This does two things. One, it makes it harder for crackers to fiddle
with your application - they never really know what they're doing or
what affect it has. Two, it makes error handling much simpler and
eliminates complex class abstractions and hierarchies.
In most cases, these bits of code is what I use:
set_error_handler('myhandler');
if( $majorproblem ) {
trigger_error('This is a major problem',E_USER_ERROR);
}
Then, the myhandler() function could look like:
function myhandler( $message,$code ) {
mail('siteadmin at domain.com','MAJOR PROBLEM
at'.time(),trigger_dump($GLOBALS));
error_log('MAJOR PROBLEM at '.time().trigger_dump($GLOBALS));
go2('/error.php');
exit;
}
I know that code won't really work and is horribly sloppy; if anyone
wants real code, let me know. go2() is part of the this_server PCOM
(http://pcomd.net/this_server) to handler redirections and
trigger_dump() is the PCOM at http://pcomd.net/trigger_dump as a wrapper
for dumping variables.
While many are probably shocked by the no-frills approach to this error
handling scheme, it's all I've never needed. It's very "un-enterprise"
I know. Look at it this way, when something goes wrong:
-- you need to know the state of the application; trigger_dump($GLOBALS)
-- you need to know when it happened; time()
-- you need to know that it happened; mail()
-- you need to have a record of the above three items; error_log()
-- you need to prevent the user from knowing any of this, except that it
happened; go2()
I'm also curious as to other's approach. Granted, in PHP 5 we'll have
exceptions - which are a great thing - but doesn't really change that
much. Exceptions are for *detecting* errors, no handling after the
fact. I'm curious as to other's thoughts.
H
>From hans not junk at nyphp.com Mon May 10 21:51:29 2004
Return-Path: <hans not junk at nyphp.com>
Received: from ehost011-1.intermedia.net (unknown [64.78.21.3])
by virtu.nyphp.org (Postfix) with ESMTP id 71F57A862D
for <talk at lists.nyphp.org>; Mon, 10 May 2004 21:51:29 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nycphp-talk] re: Wiki anti-spam CAPTCHA patch: $_SESSION conflict
Date: Mon, 10 May 2004 18:51:25 -0700
Message-ID: <41EE526EC2D3C74286415780D3BA9F8701E444B5 at ehost011-1.exch011.intermedia.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nycphp-talk] re: Wiki anti-spam CAPTCHA patch: $_SESSION conflict
Thread-Index: AcQuytUedhhNudgjSOSQmiKtabR/QgIL4BMw
From: "Hans Zaunere" <hans not junk at nyphp.com>
To: "NYPHP Talk" <talk at lists.nyphp.org>
X-BeenThere: talk at lists.nyphp.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: NYPHP Talk <talk at lists.nyphp.org>
List-Id: NYPHP Talk <talk.lists.nyphp.org>
List-Unsubscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
<mailto:talk-request at lists.nyphp.org?subject=unsubscribe>
List-Archive: <http://lists.nyphp.org/pipermail/talk>
List-Post: <mailto:talk at lists.nyphp.org>
List-Help: <mailto:talk-request at lists.nyphp.org?subject=help>
List-Subscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
<mailto:talk-request at lists.nyphp.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2004 01:51:29 -0000
> I just found an answer to my own question. I used=20
> session_name() to rename the session.
>=20
> The funny thing is that on Windows (my local test machine)=20
> having two scripts accessing a session with the same name did=20
> not cause a problem, whereas on the Linux production server it did.
>=20
> On both session autostart is turned off ...
>=20
> I am not sure why Win and Lin reacted differently here.
Bam... another good topic for an article? This would be quite a tricky
article, though, since the difference can be very subtle and complex.
Good it's resolved Jayesh,
H
More information about the talk
mailing list