Can anyone think of a situation where you actually want our current
ignore_user_abort=false setting for the cli sapi?
-Rasmus
Maybe to make it respond to SIGHUP signals? Not exactly sure whether
that would constitute as user_abort though.
Can anyone think of a situation where you actually want our current
ignore_user_abort=false setting for the cli sapi?-Rasmus
--
--
Tjerk
No, ignore_user_abort has no effect on what the process does when it
receives a SIGHUP, so that isn't relevant.
-Rasmus
Tjerk Anne Meesters wrote:
Maybe to make it respond to
SIGHUPsignals? Not exactly sure whether
that would constitute as user_abort though.Can anyone think of a situation where you actually want our current
ignore_user_abort=false setting for the cli sapi?-Rasmus
2009/12/23 Rasmus Lerdorf rasmus@lerdorf.com:
Can anyone think of a situation where you actually want our current
ignore_user_abort=false setting for the cli sapi?
I would say that the default setting is pretty important as pressing
CTRL+C (at least on windows) is the quickest way of killing a PHP cli
based script without killing the shell/console or loading the task
manager (or similar), finding the right instance of PHP and then
killing it.
Richard.
--
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Richard Quadling wrote:
2009/12/23 Rasmus Lerdorf rasmus@lerdorf.com:
Can anyone think of a situation where you actually want our current
ignore_user_abort=false setting for the cli sapi?I would say that the default setting is pretty important as pressing
CTRL+C (at least on windows) is the quickest way of killing a PHP cli
based script without killing the shell/console or loading the task
manager (or similar), finding the right instance of PHP and then
killing it.
Again, ignore_user_abort has no effect on signal handling. A SIGTERM is
going to kill the process regardless of the ignore_user_abort setting.
ignore_user_abort is a simple boolean that guides whether to abort when
PHP is unable to write to whatever output mechanism the sapi uses. For
cli that would be stdout. If for some reason your cli script's tty goes
away without the script being terminated then your script will die the
next time it tries to write anything because ignore_user_abort is off by
default. One situation where this is likely is when you specifically
background and nohup your cli script. Right now unless you also set
ignore_user_abort to true in your script, it will die on any sort of
output. There are other cases as well.
-Rasmus
Richard Quadling wrote:
2009/12/23 Rasmus Lerdorf rasmus@lerdorf.com:
Can anyone think of a situation where you actually want our current
ignore_user_abort=false setting for the cli sapi?I would say that the default setting is pretty important as pressing
CTRL+C (at least on windows) is the quickest way of killing a PHP
cli
based script without killing the shell/console or loading the task
manager (or similar), finding the right instance of PHP and then
killing it.Again, ignore_user_abort has no effect on signal handling. A SIGTERM
is
going to kill the process regardless of the ignore_user_abort setting.ignore_user_abort is a simple boolean that guides whether to abort
when
PHP is unable to write to whatever output mechanism the sapi uses.
For
cli that would be stdout. If for some reason your cli script's tty
goes
away without the script being terminated then your script will die the
next time it tries to write anything because ignore_user_abort is off
by
default. One situation where this is likely is when you specifically
background and nohup your cli script. Right now unless you also set
ignore_user_abort to true in your script, it will die on any sort of
output. There are other cases as well.
If my SSH session conks out, I'd kind of like it to just kill of the
PHP process by default, since I'll try to log back in and start over.
I guess that's a reasonable expectation to keep it that way.
I realize, of course, that a Un*x guru like you is going to know some
fancy dancy way to re-attach your new tty/shell thingie to the
still-running PHP process when you log back in, but your average
developer, not so much. :-)
I probably have unknowingly relied on this behaviour more times than I
can count, personally.
I could probably get used to it if it changed though.
Actually, for a long-running php script, or a shaky connection, I
usually re-direct to a log file and background it, but even that is
more than some "Devs" are going to "get".
--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch