[PHP] concatenating class instances?
Hi,
Quick question. The below code snippet responded in a way that I didn't
expect. I created an instance of the class frameWork, and then created an
instance of the section class which is assigned to the same variable. I
thought that the second instance would overwrite the frameWork object.
Instead, I discovered that the frameWork object instead inherited the
methods and properties of the new object, while maintaining the methods and
properties of the old object.
require_once('libraries/frameWork.php');
$frameWork = new frameWork;
include('libraries/section.php');
$frameWork = new section;
Am I correct to assume that this is the default behavior in the above
circumstance?
Thanks,
Michael
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] howto kill proc stream after X seconds
Hi,
I am struggling to find a way to kill a proc_open() stream if it remains
idle (hangs). Specifically, I am opening an SSH connection up and running a
remote command - all from a PHP script run from the shell. Under the rare
circumstance that my passwordless authentication fails (ie: it sits there
waiting for a password), I want to be able to 1) check to see if this is the
case 2) kill the stream 3) move on to other tasks. My "solution" (it
doesn't work) has been to set blocking to false, and check to see if it
continues looping in the fread() for 5 seconds. If the loop is > 5 seconds,
I try to send a CTRL-C to the opened ssh command, break out of the loop and
move on. But, the CTRL-C doesn't kill the ssh command, and the script gets
stuck (ie: it doesn't do it's var_export) until I manually CTRL-C from the
shell. looks like this so far:
$spec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("file", "/tmp/error-output.txt", "a")
);
$process = proc_open(''ssh somehost someremotecommand';', $spec, $pipes);
if (is_resource($process)) {
stream_set_blocking($pipes[1], false);
stream_set_blocking($pipes[0], false);
$contents = '';
$time = time();
while (!feof($pipes[1])) {
$contents .= fread($pipes[1], 8192);
if (time() - $time > 5) {
// send ctrl-c
fwrite($pipes[0], chr(4));
break;
}
}
fclose($pipes[0]);
fclose($pipes[1]);
$return_value = proc_close($process);
}
var_export($contents);
die();
Any ideas on how I can do this?
CONFIDENTIALITY NOTICE
This message contains confidential information intended only for the use of
the individual or entity named as recipient. Any dissemination, distribution
or copying of this communication by anyone other than the intended recipient
is strictly prohibited. If you have received this message in error, please
immediately notify us and delete your copy. Thank you.
AVIS DE CONFIDENTIALITÉ
Les informations contenues aux présentes sont de nature privilégiée et
confidentielle. Elles ne peuvent être utilisées que par la personne ou
l'entité dont le nom paraît comme destinataire. Si le lecteur du présent
message n'est pas le destinataire prévu, il est par les présentes prié de
noter qu'il est strictement interdit de divulguer, de distribuer ou de
copier ce message. Si ce message vous a été transmis par mégarde, veuillez
nous en aviser immédiatement et supprimer votre copie. Merci.
[PHP] Parse Errors with 5.2 on Linux
Hi there, I just installed PHP 5.2 on a linux server (compiled from source), and am having some strange problems with a script that is reporting a fatal parse error: Parse error: syntax error, unexpected $end in /xxx/xxx/xxx/functions.php on line 1213 This very script parses just a-okay under PHP 5.1.6 (linux), and, mysteriously, 5.2 on windows. I'm sure that the file is identical across all three servers. The file is pulled from a subversion repository, so it should be identical. Any ideas? Thanks, Mike
RE: [PHP] Parse Errors with 5.2 on Linux
Hi Richard,
Thanks for the reply. I tracked the problem down to short tags being
turned off in the php.ini (I know, short tags, bad, bad). That fixed
it.
Thanks,
Mike
-Original Message-
From: Richard Lynch [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 07, 2006 1:39 PM
To: Michael Caplan
Cc: php-general@lists.php.net
Subject: Re: [PHP] Parse Errors with 5.2 on Linux
On Tue, November 7, 2006 11:30 am, Michael Caplan wrote:
> I just installed PHP 5.2 on a linux server (compiled from source), and
> am having some strange problems with a script that is reporting a
> fatal
> parse error:
>
> Parse error: syntax error, unexpected $end in
> /xxx/xxx/xxx/functions.php
> on line 1213
>
> This very script parses just a-okay under PHP 5.1.6 (linux), and,
> mysteriously, 5.2 on windows.
>
> I'm sure that the file is identical across all three servers. The
> file
> is pulled from a subversion repository, so it should be identical.
> Any
> ideas?
That usually means an unmatched { or ( or " or ' etc...
So, basically, I'd suggesting copying the files over by hand with FTP
or something and doing a 'diff' to be 100% sure you have the whole
file.
It's also remotely possible that something changed in 5.2...
I never have understood why it was kosher to leave the final ?> off,
for example, so maybe that changed. :-) [I doubt it]
At any rate, you have to confirm that the file *IS* complete first.
After that, post the file if you can, or we've got nothing to say
about it, really...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Strategies for debugging a segmentation fault on a production ser ver
Hi there, I am looking for some advice on how to go about debugging Apache 1.3.33 / PHP 5.0.4 on a production Linux box (RHE 3). The scenario is this: Once a day we find a segfault in our apache logs. From our current position, we don't know what page was accessed, and our 400+ users haven't brought the issue to our attention. All we know is the date/time and PID of when the segfault occurred. The question is this: how can we go about isolating the offending requested page that bombs? I've set up a custom apache log file that populates each entry with the PID that handled it. However, when we do see a segfault, this log file does not appear to be populated with an entry that corresponds (within a 5 - 10 second period) to the PID that bombs. I'm guessing that the log file is only written to after a request is delivered? Otherwise, looking at the PHP bugs page, it recommends rebuilding PHP with -enable-debug and running Apache with -X in order to get a core dump. Running apache with debug mode on is not an option on our production box. Is running apache -X mandatory to get a core dump? Any other strategies that you can recommend that would help us isolate the offending page so we can get to the good work of reproducing and fixing the problem at hand? Thanks! Michael CONFIDENTIALITY NOTICE This message contains confidential information intended only for the use of the individual or entity named as recipient. Any dissemination, distribution or copying of this communication by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify us and delete your copy. Thank you. AVIS DE CONFIDENTIALITÉ Les informations contenues aux présentes sont de nature privilégiée et confidentielle. Elles ne peuvent être utilisées que par la personne ou l'entité dont le nom paraît comme destinataire. Si le lecteur du présent message n'est pas le destinataire prévu, il est par les présentes prié de noter qu'il est strictement interdit de divulguer, de distribuer ou de copier ce message. Si ce message vous a été transmis par mégarde, veuillez nous en aviser immédiatement et supprimer votre copie. Merci.
[PHP] Local session.gc_maxlifetime not always being respected
Hi, I have a rather peculiar problem with session.gc_maxlifetime local settings not being respected under certain circumstances. In order to ensure that sessions created for our application would have a max lifetime longer than the default 24 minutes, we cranked session.gc_maxlifetime in an .htaccess file to 4 hours (local value). However, our sessions where still being clean up after 24 minutes. I validated through phpinfo() that it was actually picking up the local setting, which it was. I also noticed in my testing that if I reduced the session.gc_maxlifetime local value to less than the master value, my sessions would be cleaned up in accordance to the local value. When we changed the master value to 4 hours, we are no longer having our sessions cleaned up within 24 minutes. So, it appears that the local value of session.gc_maxlifetime is only being respected if it is less than that of the master value. Has anyone else come across this problem as well? FYI, we are running PHP 4.4 on debian sarge. Thanks, Michael -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Local session.gc_maxlifetime not always being respected
Hi, I have a rather peculiar problem with session.gc_maxlifetime local settings not being respected under certain circumstances. In order to ensure that sessions created for our application would have a max lifetime longer than the default 24 minutes, we cranked session.gc_maxlifetime in an .htaccess file to 4 hours (local value). However, our sessions where still being clean up after 24 minutes. I validated through phpinfo() that it was actually picking up the local setting, which it was. I also noticed in my testing that if I reduced the session.gc_maxlifetime local value to less than the master value, my sessions would be cleaned up in accordance to the local value. When we changed the master value to 4 hours, we are no longer having our sessions cleaned up within 24 minutes. So, it appears that the local value of session.gc_maxlifetime is only being respected if it is less than that of the master value. Has anyone else come across this problem as well? FYI, we are running PHP 4.4 on debian sarge. Thanks, Michael -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
