php-general Digest 15 Jan 2011 05:50:57 -0000 Issue 7133
Topics (messages 310759 through 310776):
Re: Bare Strings, are they deprecated?
310759 by: larry.garfieldtech.com
310760 by: Richard Quadling
310761 by: Evil Son
310762 by: Richard Quadling
310763 by: Evil Son
Exec Script in the background, don't wait till it finishes
310764 by: Kai Renz
310765 by: Nicholas Kell
310766 by: Daniel Brown
310767 by: Evil Son
310768 by: Daniel Brown
310769 by: Kai Renz
310770 by: Nicholas Kell
310771 by: Nicholas Kell
310773 by: Richard Quadling
'make test' failures
310772 by: Jesse Williams
310776 by: Nilesh Govindarajan
Re: Rewriting string
310774 by: David McGlone
which php file is sending emails?
310775 by: Mesut GULNAZ
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Assuming that by "bare strings" you mean:
$foo[bar] = 'baz';
as opposed to:
$foo['bar'] = 'baz';
That is generally considered very bad form in PHP. That throws an
E_NOTICE error level, and therefore slows down your code (if only by a
small amount) for the error handling. Of course, if you have any
respect for your code you're developing under E_ALL so bare strings for
array keys would print ugly notices messages at you constantly. If
you're not developing under E_ALL, then you're going to miss error
messages that will take a long time to track down and correct yourself
when the PHP interpreter can simply tell you exactly where they are if
you let it.
Bottom line: Bare strings are not officially deprecated, but no
respectable programmer users them.
(I now expect to get flamed by someone who uses them but is insulted
that I am calling them not respectable. My position on the matter still
stands.)
--Larry Garfield
On 1/14/11 9:44 AM, Evil Son wrote:
Hello group,
I am a new and just an occasional user of PHP and would like some direction.
I find the use of bare strings as array keys pleasant to work with,
easy on the eye and quick to type. I understand that this use of bare
strings is not encouraged because of possible conflicts with key words
and constants and to a lesser degree loss of some performance.
I tend to use all capitals for my constants and never for my array
keys (if bare). In addition, collisions with PHP keywords fails fast
when they happen. My application is for personal use, and any
performance degradation is insignificant.
However, I can imagine having collisions with constants defined by
libraries that I may use.
Have you found the use of bare strings a significant issue? Or do the
benefits outweigh the dangers? Perl and Tcl both have them. I like
them in PHP too.
Thanks.
--- End Message ---
--- Begin Message ---
On 14 January 2011 15:51, [email protected] <[email protected]> wrote:
> (I now expect to get flamed by someone who uses them but is insulted that I
> am calling them not respectable.)
http://www.alibaba.com/product-tp/103358451/FIRE_RETARDANT_SUIT_AND_COVERALL/showimage.html
I'd lend you mine.
If I had one.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
On Sat, Jan 15, 2011 at 1:51 AM, [email protected]
<[email protected]> wrote:
> Assuming that by "bare strings" you mean:
>
> $foo[bar] = 'baz';
>
> as opposed to:
>
> $foo['bar'] = 'baz';
Yes, indeed.
> That is generally considered very bad form in PHP. That throws an E_NOTICE
> error level, and therefore slows down your code (if only by a small amount)
> for the error handling. Of course, if you have any respect for your code
> you're developing under E_ALL so bare strings for array keys would print
> ugly notices messages at you constantly. If you're not developing under
> E_ALL, then you're going to miss error messages that will take a long time
> to track down and correct yourself when the PHP interpreter can simply tell
> you exactly where they are if you let it.
My first little app which is about an hour old is a command line
utility for personal use and to be honest, I haven't checked the logs
or the settings of php.ini so I don't know what the warning level is
set at. I did not know that the interpreter emitted such a warning for
bare strings. So it's settled for me: check my php.ini to ensure that
I run at E_ALL | E_STRICT | E_NOTICE and refrain from using bare
strings.
Thanks for your thoughts and the reminder.
Regards.
> Bottom line: Bare strings are not officially deprecated, but no respectable
> programmer users them.
>
> (I now expect to get flamed by someone who uses them but is insulted that I
> am calling them not respectable. My position on the matter still stands.)
>
> --Larry Garfield
>
> On 1/14/11 9:44 AM, Evil Son wrote:
>>
>> Hello group,
>>
>> I am a new and just an occasional user of PHP and would like some
>> direction.
>>
>> I find the use of bare strings as array keys pleasant to work with,
>> easy on the eye and quick to type. I understand that this use of bare
>> strings is not encouraged because of possible conflicts with key words
>> and constants and to a lesser degree loss of some performance.
>>
>> I tend to use all capitals for my constants and never for my array
>> keys (if bare). In addition, collisions with PHP keywords fails fast
>> when they happen. My application is for personal use, and any
>> performance degradation is insignificant.
>>
>> However, I can imagine having collisions with constants defined by
>> libraries that I may use.
>>
>> Have you found the use of bare strings a significant issue? Or do the
>> benefits outweigh the dangers? Perl and Tcl both have them. I like
>> them in PHP too.
>>
>> Thanks.
>>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Regards
Evil Son
--- End Message ---
--- Begin Message ---
On 14 January 2011 16:06, Evil Son <[email protected]> wrote:
> On Sat, Jan 15, 2011 at 1:51 AM, [email protected]
> <[email protected]> wrote:
>> Assuming that by "bare strings" you mean:
>>
>> $foo[bar] = 'baz';
>>
>> as opposed to:
>>
>> $foo['bar'] = 'baz';
>
> Yes, indeed.
>
>> That is generally considered very bad form in PHP. That throws an E_NOTICE
>> error level, and therefore slows down your code (if only by a small amount)
>> for the error handling. Of course, if you have any respect for your code
>> you're developing under E_ALL so bare strings for array keys would print
>> ugly notices messages at you constantly. If you're not developing under
>> E_ALL, then you're going to miss error messages that will take a long time
>> to track down and correct yourself when the PHP interpreter can simply tell
>> you exactly where they are if you let it.
>
> My first little app which is about an hour old is a command line
> utility for personal use and to be honest, I haven't checked the logs
> or the settings of php.ini so I don't know what the warning level is
> set at. I did not know that the interpreter emitted such a warning for
> bare strings. So it's settled for me: check my php.ini to ensure that
> I run at E_ALL | E_STRICT | E_NOTICE and refrain from using bare
> strings.
>
> Thanks for your thoughts and the reminder.
>
> Regards.
>
>
>> Bottom line: Bare strings are not officially deprecated, but no respectable
>> programmer users them.
>>
>> (I now expect to get flamed by someone who uses them but is insulted that I
>> am calling them not respectable. My position on the matter still stands.)
>>
>> --Larry Garfield
>>
>> On 1/14/11 9:44 AM, Evil Son wrote:
>>>
>>> Hello group,
>>>
>>> I am a new and just an occasional user of PHP and would like some
>>> direction.
>>>
>>> I find the use of bare strings as array keys pleasant to work with,
>>> easy on the eye and quick to type. I understand that this use of bare
>>> strings is not encouraged because of possible conflicts with key words
>>> and constants and to a lesser degree loss of some performance.
>>>
>>> I tend to use all capitals for my constants and never for my array
>>> keys (if bare). In addition, collisions with PHP keywords fails fast
>>> when they happen. My application is for personal use, and any
>>> performance degradation is insignificant.
>>>
>>> However, I can imagine having collisions with constants defined by
>>> libraries that I may use.
>>>
>>> Have you found the use of bare strings a significant issue? Or do the
>>> benefits outweigh the dangers? Perl and Tcl both have them. I like
>>> them in PHP too.
>>>
>>> Thanks.
>>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
> Regards
> Evil Son
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
error_reporting=-1
display_errors=On
will turn on everything and tell you about it.
Alternatively, take a look at the setting of php.ini-development. This
is the recommended settings for developing with PHP, as opposed to
php.ini-production which is the recommend settings for running PHP in
a live environment.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
On Sat, Jan 15, 2011 at 2:19 AM, Richard Quadling <[email protected]> wrote:
>
> error_reporting=-1
> display_errors=On
>
> will turn on everything and tell you about it.
Yes I see them now! Ghastly!
> Alternatively, take a look at the setting of php.ini-development. This
> is the recommended settings for developing with PHP, as opposed to
> php.ini-production which is the recommend settings for running PHP in
> a live environment.
Now using "development".
> --
> Richard Quadling
> Twitter : EE : Zend
> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
>
Thanks.
--
Regards
Evil Son
--- End Message ---
--- Begin Message ---
Hi there,
i'm currently working on a socket project. It consists of two scripts.
The first script (socket1.php) creates a socket on a specified port
and waits for a client to connect. If a client connects, they exchange
some informations, including a random created port. Next, the first
script calls the second script (socket2.php) with the just created
port number as a parameter.
Now here is the problem:
it all works fine, but the client can't send a quit message to socket1
because socket1.php waits until socket2.php is finished. socket2.php
is working properly, and if i connect to the new socket and quit the
connection, socket1 is working again. All i need socket1 to do is to
continue working independant of socket2.
I tried everything, from shell_exec to pcntl_exec, nothing seems to work.
regards,
Kai
--- End Message ---
--- Begin Message ---
On Jan 14, 2011, at 10:56 AM, Kai Renz wrote:
> Hi there,
>
> i'm currently working on a socket project. It consists of two scripts.
> The first script (socket1.php) creates a socket on a specified port
> and waits for a client to connect. If a client connects, they exchange
> some informations, including a random created port. Next, the first
> script calls the second script (socket2.php) with the just created
> port number as a parameter.
>
> Now here is the problem:
> it all works fine, but the client can't send a quit message to socket1
> because socket1.php waits until socket2.php is finished. socket2.php
> is working properly, and if i connect to the new socket and quit the
> connection, socket1 is working again. All i need socket1 to do is to
> continue working independant of socket2.
>
> I tried everything, from shell_exec to pcntl_exec, nothing seems to work.
>
> regards,
> Kai
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
To the best of my knowledge you are kind of in a hard place with that type of
situation.
I hate to be the guy that in the last three weeks mentions using a different
language for an issue, but I honestly think that you may have a higher return
using a language that supports threads a bit better. Hope this doesn't start
another language battle.
Don't get me wrong, I love PHP, but there are certain things that a different
tool may be easier to solve the problem with.
PHP or not: Could you describe the issue a bit more? What is the goal, at the
end of the day?
Here is what I am gathering:
Open a socket
client connects
get client to a different port to run independently
Can I assume that the goal of moving them to a different port is to be able to
accept more clients on the first port?
--- End Message ---
--- Begin Message ---
On Fri, Jan 14, 2011 at 11:56, Kai Renz <[email protected]> wrote:
>
> Now here is the problem:
> it all works fine, but the client can't send a quit message to socket1
> because socket1.php waits until socket2.php is finished. socket2.php
> is working properly, and if i connect to the new socket and quit the
> connection, socket1 is working again. All i need socket1 to do is to
> continue working independant of socket2.
>
> I tried everything, from shell_exec to pcntl_exec, nothing seems to work.
Have you looked into pcntl_fork() or running it in the background
via something as simple as backticks? The latter of which,
exemplified:
<?php
`/bin/env php /path/to/socket2.php --port 1234 >> /path/to/log.txt 2>&1 &`;
?>
Expanding on that, you could do something like this:
<?php
exec('/bin/env php /path/to/socket2.php --port 1234 >>
/path/to/log.txt 2>&1 &',$ret,$err);
if ($err === 0) {
exec('echo $$',$ret);
$pid = $response[0];
echo $pid.PHP_EOL;
} else {
echo 'There was an error while forking the process. Please
view the log.'.PHP_EOL;
}
?>
--
</Daniel P. Brown>
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/
--- End Message ---
--- Begin Message ---
Sorry, not sent to the list.
---------- Forwarded message ----------
From: Evil Son <[email protected]>
Date: Sat, Jan 15, 2011 at 4:26 AM
Subject: Re: [PHP] Exec Script in the background, don't wait till it finishes
To: Kai Renz <[email protected]>
On Sat, Jan 15, 2011 at 2:56 AM, Kai Renz <[email protected]> wrote:
> Hi there,
>
> i'm currently working on a socket project. It consists of two scripts.
> The first script (socket1.php) creates a socket on a specified port
> and waits for a client to connect. If a client connects, they exchange
> some informations, including a random created port. Next, the first
> script calls the second script (socket2.php) with the just created
> port number as a parameter.
>
> Now here is the problem:
> it all works fine, but the client can't send a quit message to socket1
> because socket1.php waits until socket2.php is finished. socket2.php
> is working properly, and if i connect to the new socket and quit the
> connection, socket1 is working again. All i need socket1 to do is to
> continue working independant of socket2.
>
> I tried everything, from shell_exec to pcntl_exec, nothing seems to work.
Looking at the manual, shell_exec will wait for the other script to
return (just like calling the 2nd script"), pcntl_exec replaces the
original server with the new one. pcntl_fork is what you want but it
is non-windows. Hopefully you are running on *nix.
HTH
--
Regards
Evil Son
--
Regards
Evil Son
--- End Message ---
--- Begin Message ---
On Fri, Jan 14, 2011 at 13:28, Kai Renz <[email protected]> wrote:
(Putting this back on the list. Please use Reply-All.)
> @Daniel:
> Yeh i tried sending it to the background, this works but still it does
> wait for the other script to finish.
It shouldn't. In fact, just to see if I somehow completely forgot
how things worked, I just mocked up the following and verified it
worked perfectly:
<?php
// 1.php
`php ./2.php >> /dev/null 2>&1 &`;
echo 'I will now terminate, while the other script continues.'.PHP_EOL;
?>
<?php
// 2.php
while (1) {
file_put_contents('./123-whee.txt','I\'m still
running!'.PHP_EOL,FILE_APPEND);
}
?>
dan@blackbox:~$ php 1.php
I will now terminate, while the other script continues.
dan@blackbox:~$ tail -f ./123-whee.txt
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
I'm still running!
^C
dan@blackbox:~$ ps -ef | grep -i php
dan 29428 1 34 13:37 pts/166 00:00:24 php ./2.php
dan 29491 28729 0 13:38 pts/166 00:00:00 grep --color=auto -i php
--
</Daniel P. Brown>
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/
--- End Message ---
--- Begin Message ---
Hi guys and thanks for your answers...
@Nicholas:
Yes, you are right. The first socket is only used if a new clients
connects, thats why the script generates a new port so the client can
connect to the new socket. After that socket1 should continue its work
and wait for new clients.
@Daniel:
Yeh i tried sending it to the background, this works but still it does
wait for the other script to finish.
@Evil Son:
Thanks for the tip, i'll try it :)
--- End Message ---
--- Begin Message ---
On Jan 14, 2011, at 12:41 PM, Kai Renz wrote:
> Hi guys and thanks for your answers...
>
> @Nicholas:
> Yes, you are right. The first socket is only used if a new clients
> connects, thats why the script generates a new port so the client can
> connect to the new socket. After that socket1 should continue its work
> and wait for new clients.
>
> @Daniel:
> Yeh i tried sending it to the background, this works but still it does
> wait for the other script to finish.
>
> @Evil Son:
> Thanks for the tip, i'll try it :)
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
One more thing to verify: What is the target environment? *nix I hope.
--- End Message ---
--- Begin Message ---
On Jan 14, 2011, at 12:41 PM, Kai Renz wrote:
> Hi guys and thanks for your answers...
>
> @Nicholas:
> Yes, you are right. The first socket is only used if a new clients
> connects, thats why the script generates a new port so the client can
> connect to the new socket. After that socket1 should continue its work
> and wait for new clients.
>
> @Daniel:
> Yeh i tried sending it to the background, this works but still it does
> wait for the other script to finish.
>
> @Evil Son:
> Thanks for the tip, i'll try it :)
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Your not going to be able to push it to the background, it will always wait no
matter where you push it.
You will have to spawn another full script. The pcntl_fork() function is what
you are looking for, but it works a tad less than optimal in this situation.
Here is a QnD of a class and using it. This thing creates a bit of a mess, but
it illustrates that the parent doesn't wait on the child to die.
You will need to write some logic to determine if it is the parent or child
fork that is running, and also keep track of your ports.
Like I said earlier, it creates a mess, but clearly illustrates pcntl_fork();
This is a messy thing to be implementing in PHP.
<?php
$_pid = getmypid();
echo "\n~~ Start $_pid\t";
$_port = 8080;
$_socket = new MySocket($_port);
$_socket->open();
$_socket->handleNewClient(++$_port);
$_socket->handleNewClient(++$_port);
$_socket->handleNewClient(++$_port);
$_socket->handleNewClient(++$_port);
$_socket->handleNewClient(++$_port);
echo "\n~~ End $_pid\t";
class MySocket {
private $port;
public function __construct($_port) {
$this->port = getmypid(); //Use port number if ya want - I used PID for
uniqueness
echo "\n--- Created new port $this->port\t";
}
public function open() {
echo "\nOpen port: $this->port\n";
for ($_i = 0; $_i < 100; $_i++) {// Do some thinking: Clog up the buffer
echo "[$this->port]";
}
}
public function close() {
echo "\n=== Closing $this->port\t";
}
public function handleNewClient($_port) {
$_socket = new MySocket($_port);
$_socket->open();
pcntl_fork(); // Creates an exponential mess
$_socket->close(); // Close socket after spawning another script
}
// Rest of class logic...
}
?>
--- End Message ---
--- Begin Message ---
On 14 January 2011 18:48, Nicholas Kell <[email protected]> wrote:
>
> On Jan 14, 2011, at 12:41 PM, Kai Renz wrote:
>
>> Hi guys and thanks for your answers...
>>
>> @Nicholas:
>> Yes, you are right. The first socket is only used if a new clients
>> connects, thats why the script generates a new port so the client can
>> connect to the new socket. After that socket1 should continue its work
>> and wait for new clients.
>>
>> @Daniel:
>> Yeh i tried sending it to the background, this works but still it does
>> wait for the other script to finish.
>>
>> @Evil Son:
>> Thanks for the tip, i'll try it :)
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
> One more thing to verify: What is the target environment? *nix I hope.
You can launch a non-blocking process in Windows using PHP. I do this a lot.
<?php
$o_Shell = new COM('WScript.Shell');
$o_Shell->Run('C:\\PHP5\\php-win.exe -f script.php --
script_params_would_go_here', 0, False);
// This script can now continue and script.php will be running in parallel.
?>
I use WinCache's Ucache to pass data between the multiple "threads".
Now, use the PECL extension Win32Service, and you can use PHP for
Windows Services, multi-threaded with inter-thread communication.
If you feel mad enough.
Regards,
Richard.
[1] http://msdn.microsoft.com/en-us/library/d5fk67ky(v=vs.85).aspx
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
I am attempting to compile php from source, because a couple of our developers
require a new version than what is packaged with our linux distribution (Oracle
Enterprise Linux 5.3). The code configures just fine and builds, but when I
run the 'make test' command it fails with something like this:
=====================================================================
TEST RESULT SUMMARY
---------------------------------------------------------------------
Exts skipped : 28
Exts tested : 51
---------------------------------------------------------------------
Number of tests : 9031 7604
Tests skipped : 1427 ( 15.8%) --------
Tests warned : 0 ( 0.0%) ( 0.0%)
Tests failed : 36 ( 0.4%) ( 0.5%)
Expected fail : 5 ( 0.1%) ( 0.1%)
Tests passed : 7563 ( 83.7%) ( 99.5%)
---------------------------------------------------------------------
Time taken : 959 seconds
=====================================================================
=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
easter_date() [ext/calendar/tests/easter_date.phpt]
unixtojd() [ext/calendar/tests/unixtojd.phpt]
curl_setopt() basic parameter test [ext/curl/tests/curl_setopt_error.phpt]
timezone_abbreviations_list() tests [ext/date/tests/010.phpt]
Test DateTimeZone::listAbbreviations() function : basic functionality
[ext/date/tests/DateTimeZone_listAbbreviations_basic1.phpt]
Test DateTime::modify() function : usage variation - Passing unexpected values
to first argument $modify. [ext/date/tests/DateTime_modify_variation1.phpt]
Test date_modify() function : usage variation - Passing unexpected values to
second argument $format. [ext/date/tests/date_modify_variation2.phpt]
Test timezone_abbreviations_list() function : basic functionality
[ext/date/tests/timezone_abbreviations_list_basic1.phpt]
DOMDocument::$validateOnParse - effectual determination
(dom_document_validate_on_parse_read/dom_document_validate_on_parse_write)
[ext/dom/tests/DOMDocument_validate_on_parse_variation.phpt]
Bug #43073 (TrueType bounding box is wrong for angle<>0)
[ext/gd/tests/bug43073.phpt]
Bug #48801 (Problem with imagettfbbox) [ext/gd/tests/bug48801.phpt]
Test imagecolorallocate() function : usage variations - passing different data
types to fourth argument [ext/gd/tests/imagecolorallocate_variation4.phpt]
gmp_gcd() basic tests [ext/gmp/tests/021.phpt]
gmp_cmp() basic tests [ext/gmp/tests/026.phpt]
Feature Request #50283 (allow base in gmp_strval to use full range: 2 to 62,
and -2 to -36) [ext/gmp/tests/bug50283.phpt]
ldap_bind() - Basic anonymous binding [ext/ldap/tests/ldap_bind_basic.phpt]
ldap_bind() - Advanced binding [ext/ldap/tests/ldap_bind_variation.phpt]
ldap_sasl_bind() - Basic anonymous binding
[ext/ldap/tests/ldap_sasl_bind_basic.phpt]
ldap_search() - operation that should fail
[ext/ldap/tests/ldap_search_error.phpt]
ldap_start_tls() - Basic ldap_start_tls test
[ext/ldap/tests/ldap_start_tls_basic.phpt]
Bug #41125 (PDO mysql + quote() + prepare() can result in seg fault)
[ext/pdo_mysql/tests/bug41125.phpt]
Bug #44327 (PDORow::queryString property & numeric offsets / Crash)
[ext/pdo_mysql/tests/bug44327.phpt]
Test session_encode() function : error functionality
[ext/session/tests/session_encode_error2.phpt]
SimpleXML: XPath [ext/simplexml/tests/008.phpt]
SPL: DirectoryIterator test getGroup
[ext/spl/tests/DirectoryIterator_getGroup_basic.phpt]
SPL: Spl Directory Iterator test getOwner
[ext/spl/tests/DirectoryIterator_getOwner_basic.phpt]
htmlentities() test 2 (setlocale / fr_FR.ISO-8859-15)
[ext/standard/tests/strings/htmlentities02.phpt]
htmlentities() test 4 (setlocale / ja_JP.EUC-JP)
[ext/standard/tests/strings/htmlentities04.phpt]
htmlentities() test 10 (default_charset / cp1252)
[ext/standard/tests/strings/htmlentities10.phpt]
htmlentities() test 11 (default_charset / ISO-8859-15)
[ext/standard/tests/strings/htmlentities11.phpt]
htmlentities() test 13 (default_charset / EUC-JP)
[ext/standard/tests/strings/htmlentities13.phpt]
htmlentities() test 15 (setlocale / KOI8-R)
[ext/standard/tests/strings/htmlentities15.phpt]
sysvmsg functions on non-existing queue [ext/sysvmsg/tests/005.phpt]
msg_send() data types when not serializing [ext/sysvmsg/tests/006.phpt]
Bug #42189 (xmlrpc_get_type() crashes PHP on invalid dates)
[ext/xmlrpc/tests/bug42189.phpt]
Bug #51288 (CVE-2010-0397, NULL pointer deref when no <methodName> in request)
[ext/xmlrpc/tests/bug51288.phpt]
=====================================================================
=====================================================================
EXPECTED FAILED TEST SUMMARY
---------------------------------------------------------------------
output buffering - fatalism [tests/output/ob_011.phpt]
ob_start(): Ensure unerasable buffer cannot be flushed by ob_flush()
[tests/output/ob_start_basic_unerasable_005.phpt]
Bug #42718 (unsafe_raw filter not applied when configured as default filter)
[ext/filter/tests/bug42718.phpt]
SPL: ArrayObject::exchangeArray() basic usage with object as underlying data
store. [ext/spl/tests/arrayObject_exchangeArray_basic3.phpt]
Bug #39863 (file_exists() silently truncates after a null byte)
[ext/standard/tests/file/bug39863.phpt]
=====================================================================
You may have found a problem in PHP.
=====================================================================
I have compiled multiple different times, tried different 'configure' options
and tried compiling on different machines. I've even tried different versions
(5.2.14, 5.2.17, and 5.3.5). Everytime I get some level of errors from 'make
test'. As such I'm starting to wonder if it is normal for a certain number to
tests fail, or is something going wrong with my build somewhere?
I appreciate any insight you can offer.
Thanks!
--- End Message ---
--- Begin Message ---
On 01/15/2011 02:48 AM, Jesse Williams wrote:
I am attempting to compile php from source, because a couple of our developers
require a new version than what is packaged with our linux distribution (Oracle
Enterprise Linux 5.3). The code configures just fine and builds, but when I
run the 'make test' command it fails with something like this:
They never gave 100% success for me, I use php without running make test
and it works fine for me. No problems yet, its been more than two years
like that (of course different php versions).
--
Regards,
Nilesh Govindarajan
Facebook: http://www.facebook.com/nilesh.gr
Twitter: http://twitter.com/nileshgr
Website: http://www.itech7.com
--- End Message ---
--- Begin Message ---
On Thursday, January 13, 2011 12:45:30 pm Nathan Rixham wrote:
> David McGlone wrote:
> > Hi everyone,
> >
> > I think the subject is right, or somewhere close. Anyway I am trying to
> > perform a little trickery here with links. In the following code you can
> > see where I am trying to replace the link on the current page so it's
> > not a link when on that page. I think I got the general idea of what I
> > need to do as you can see in the code I just don't know how to
> > accomplish it, if it's possible.
> >
> >
> > $categorys = array('home', 'services', 'gallery', 'about_us',
> > 'contact_us', 'testimonials');
> > foreach($categorys as $category){
> > $deadlink = $_GET['page'];
> >
> > if ($deadlink == 'page') {
>
> for a short answer, all you need to do is change the above line to:
>
> if($deadlink == $category)
>
> and as a slightly colourful variant:
>
> $categorys = array('home', 'services', 'gallery', 'about_us',
> 'contact_us', 'testimonials');
> foreach($categorys as $category){
> $temp = str_replace("_", " ", $category);
> $_GET['page'] != $category && $temp = '<a href="index.php?page='.
> $category .'">'.$replace.'</a>';
> echo "<li>{$temp}</li>" . PHP_EOL;
> }
Nathan, thanks for showing me this. I understand the code, except I don't
understand how you got by without using a conditional (if/else). If it were
me, I would have written it like:
$categorys = array('home', 'services', 'gallery', 'about_us',
'contact_us', 'testimonials');
foreach($categorys as $category){
$temp = str_replace("_", " ", $category);
if( $_GET['page'] != $category && $temp = '<a href="index.php?page='.
$category .'">') {
echo <a href="index.php?page='.$category . '">'.$replace.'</a>';
} else {
echo "<li>{$temp}</li>" ;
}
I haven't tested this code, but this is how I would have thought about going
about it.
My questions are, is this wrong? is it amaturish?
--
Blessings
David M.
--- End Message ---
--- Begin Message ---
is it possible to see which php file(s) is/are sending emails on my server
by php.ini or with any other way?
coz i have a server and i have many domains and subdomains. on my smtp
systems i saw that many random mails are being sent from www server which
has RELAY permission. I know i must not give RELAY (i can use SMTP-AUTH) but
some kind of issues i have to give it.
so i have to find the domain or subdomain and the file or files which send
this emails.
how can i solve this issue?
my system ise freebsd.
thanks...
--- End Message ---
