If php exits due to a bad commandline option it never calls module
deinitialization routines. Is that a bug or a feature?
Mike
--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
Good question. Is module startup already called at this point? Is
there a reason why you care?
At 11:34 AM 6/10/2006, Michael B Allen wrote:
If php exits due to a bad commandline option it never calls module
deinitialization routines. Is that a bug or a feature?Mike
--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
Actually it's not true either... what made you think that, Michael? Care to
describe what you're seeing?
Good question. Is module startup already called at this point? Is there a
reason why you care?At 11:34 AM 6/10/2006, Michael B Allen wrote:
If php exits due to a bad commandline option it never calls module
deinitialization routines. Is that a bug or a feature?Mike
--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
On Tue, 13 Jun 2006 05:45:26 +0200
"Steph Fox" steph@zend.com wrote:
Actually it's not true either... what made you think that, Michael? Care to
describe what you're seeing?
Consider the following php script:
#!/usr/bin/php -q -c foo
<?php ...
Apparently -c is a bad option because the script just prints usage and
exits. Now, I have an extension that writes a message to a log file when
it initializes and when it deinitializes. When the said script runs the
initialization message is logged. When the script runs normally (no bad
option) the deinitialization message is logged. When the script exits
prematurely due to a bad command option, the deinitialization routine
is not logged. This leads me to believe the deinitialization routine is
not running.
Perhaps it is or perhaps the script is being killed.
Mike
--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
Hi Michael,
Actually it's not true either... what made you think that, Michael? Care
to
describe what you're seeing?Consider the following php script:
#!/usr/bin/php -q -c foo
<?php ...Apparently -c is a bad option because the script just prints usage and
exits. Now, I have an extension that writes a message to a log file when
it initializes and when it deinitializes. When the said script runs the
initialization message is logged. When the script runs normally (no bad
option) the deinitialization message is logged. When the script exits
prematurely due to a bad command option, the deinitialization routine
is not logged. This leads me to believe the deinitialization routine is
not running.Perhaps it is or perhaps the script is being killed.
No, the script is reached OK - it's just that Zend thinks your php.ini
filepath is 'foo' as well as your file, so it hangs when it's trying to work
with them both :) You're supposed to put a path after the -c switch... but
PHP really shouldn't hang when you don't.
Patch for CLI sapi (5_2 branch) attached, if someone'd like to check it for
misdemeanours/apply it?
- Steph
Mike
--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/--
__________ NOD32 1.1380 (20060125) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com