[PHP-DOC] cvs: phpdoc /en/reference/ldap/functions ldap-list.xml ldap-read.xml ldap-search.xml
takagi Sat Feb 10 03:56:30 2007 UTC Modified files: /phpdoc/en/reference/ldap/functions ldap-list.xml ldap-read.xml ldap-search.xml Log: typo fix. http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/ldap/functions/ldap-list.xml?r1=1.5&r2=1.6&diff_format=u Index: phpdoc/en/reference/ldap/functions/ldap-list.xml diff -u phpdoc/en/reference/ldap/functions/ldap-list.xml:1.5 phpdoc/en/reference/ldap/functions/ldap-list.xml:1.6 --- phpdoc/en/reference/ldap/functions/ldap-list.xml:1.5Sun Feb 4 22:48:23 2007 +++ phpdoc/en/reference/ldap/functions/ldap-list.xmlSat Feb 10 03:56:30 2007 @@ -1,5 +1,5 @@ - + ldap_list @@ -115,7 +115,7 @@ -This parameter can NOT override server-side preset sizelimit. You can +This parameter can NOT override server-side preset timelimit. You can set it lower though. http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/ldap/functions/ldap-read.xml?r1=1.4&r2=1.5&diff_format=u Index: phpdoc/en/reference/ldap/functions/ldap-read.xml diff -u phpdoc/en/reference/ldap/functions/ldap-read.xml:1.4 phpdoc/en/reference/ldap/functions/ldap-read.xml:1.5 --- phpdoc/en/reference/ldap/functions/ldap-read.xml:1.4Sun Feb 4 22:48:23 2007 +++ phpdoc/en/reference/ldap/functions/ldap-read.xmlSat Feb 10 03:56:30 2007 @@ -1,5 +1,5 @@ - + ldap_read @@ -114,7 +114,7 @@ -This parameter can NOT override server-side preset sizelimit. You can +This parameter can NOT override server-side preset timelimit. You can set it lower though. http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/ldap/functions/ldap-search.xml?r1=1.9&r2=1.10&diff_format=u Index: phpdoc/en/reference/ldap/functions/ldap-search.xml diff -u phpdoc/en/reference/ldap/functions/ldap-search.xml:1.9 phpdoc/en/reference/ldap/functions/ldap-search.xml:1.10 --- phpdoc/en/reference/ldap/functions/ldap-search.xml:1.9 Sun Feb 4 22:48:23 2007 +++ phpdoc/en/reference/ldap/functions/ldap-search.xml Sat Feb 10 03:56:30 2007 @@ -1,5 +1,5 @@ - + ldap_search @@ -129,7 +129,7 @@ -This parameter can NOT override server-side preset sizelimit. You can +This parameter can NOT override server-side preset timelimit. You can set it lower though.
Re: [PHP-DOC] MySQLi extension
This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me "i wonder if we can create a way to store "important" items across translations, like for example, deprecated status (ex. mysqli from that thread)" After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: etc. (remember, &warn.experimental; is translated) That way, this sort of thing would never happen (once the &status.foo; entities make it into the various reference.xml files. bah.. the more the entities, the slower the build becomes. So, let's not interfere with translators work :P Nuno Sure it would add one new entity per extension (that would be used in each translation) so although this is a lot I don't feel the slower build time (wonder how much?) is reason enough to not do it. If we do this, the status of all extensions in every translation will be correct and doing this requires zero additional work for translators. Because most translations are on life support (let's not talk about that now), this feature is even more important. BUT, what else will it lead to? Can we come up with a different/better solution that also takes into account other things, like prototypes? Livedocs? A big +1 on the idea. Who is working on the mega patch? I heard Mehdi is but don't know for sure :) And on a related note, what about having a docweb tool scan for EXPERIMENTAL files in php- src, the stable state in PECL (keeping in mind branching), and compare this information to this new status file. Something like that might even help all three locations stay updated. And, should we keep track (document) _when_ extensions became stable? Regards, Philip
Re: [PHP-DOC] MySQLi extension
Hello, Philip Olson wrote: - Original Message - This was already fixed in the English translation, so it's up to the Germans to catch up (-: On that note, Philip just said to me "i wonder if we can create a way to store "important" items across translations, like for example, deprecated status (ex. mysqli from that thread)" After a bit of brainstorming, we came up with the idea of creating extension-specific status entities that reference an extension's status, globally (because this sort of thing isn't translation specific). For example, we'd add new global entities: etc. (remember, &warn.experimental; is translated) That way, this sort of thing would never happen (once the &status.foo; entities make it into the various reference.xml files. bah.. the more the entities, the slower the build becomes. So, let's not interfere with translators work :P Nuno Sure it would add one new entity per extension (that would be used in each translation) so although this is a lot I don't feel the slower build time (wonder how much?) is reason enough to not do it. If we do this, the status of all extensions in every translation will be correct and doing this requires zero additional work for translators. Because most translations are on life support (let's not talk about that now), this feature is even more important. BUT, what else will it lead to? Can we come up with a different/better solution that also takes into account other things, like prototypes? Livedocs? A big +1 on the idea. Who is working on the mega patch? Mehdi
[PHP-DOC] cvs: phpdoc /en/install/windows installermsi.xml
jmertic Fri Feb 9 21:03:35 2007 UTC Modified files: /phpdoc/en/install/windows installermsi.xml Log: Updated feature list to remove pws4 and iis3 since those have been rolled into iis4cgi. http://cvs.php.net/viewvc.cgi/phpdoc/en/install/windows/installermsi.xml?r1=1.4&r2=1.5&diff_format=u Index: phpdoc/en/install/windows/installermsi.xml diff -u phpdoc/en/install/windows/installermsi.xml:1.4 phpdoc/en/install/windows/installermsi.xml:1.5 --- phpdoc/en/install/windows/installermsi.xml:1.4 Thu Nov 16 20:38:42 2006 +++ phpdoc/en/install/windows/installermsi.xml Fri Feb 9 21:03:34 2007 @@ -1,5 +1,5 @@ - + Windows Installer (PHP 5.2 and later) @@ -96,10 +96,8 @@ apache20 - Apache 2.0 module apache22 - Apache 2,2 module apacheCGI - Apache CGI executable -iis4ISAPI - IIS 4+ ISAPI module -iis4CGI - IIS 4+ CGI executable -pws4 - PWS 4 CGI executable -iis3 - IIS/PWS 3 CGI executable +iis4ISAPI - IIS ISAPI module +iis4CGI - IIS CGI executable NSAPI - Sun/iPlanet/Netscape server module Xitami - Xitami CGI executable Sambar - Sambar Server ISAPI module
[PHP-DOC] #40395 [Asn]: PCRE engine unable to output NULL characters
ID: 40395 User updated by: jfrim at idirect dot com Reported By: jfrim at idirect dot com Status: Assigned Bug Type: Documentation problem Operating System: * PHP Version: * Assigned To: nlopess New Comment: The code from my [2007-02-08 19:59:04] post shows only 0x00 and 0x22 being escaped. Maybe single-quote (0x27) only gets escaped depending on the PHP.INI settings? I may check into this later. If nothing is changed in the PHP code, the best work-around I could come up with is this: Always use the "e" modifier, and in the replacement string for preg_replace(), surround the back-reference with a pair of str_replace(), one to handle 0x00 and one for 0x22. Example: This example takes a string, and turn each byte into "0x" followed by the two digit hex code. Note the first str_replace() turns the \0 into a proper NULL, and the second nested str_replace() turns the \" into just " . It's a very dirty work-around, because preg_replace() is useless without the "e" modifier (adds processing overhead), and str_replace() has to be called twice (adds processing overhead again), and the number of backslashes in the source code is tremendous and can get confusing! And we still have a potential problem remaining. If just which characters are escaped and which ones aren't is dependant on the PHP.INI settings (ie. regarding double-quote and single-quote), then it's impossible for this dirty work-around to be portable, unless the entire thing is encapsulated in an if() or switch() block. That's REALLY dirty! The reason why stripslashes() can't be used on the back-reference is because the backslash character, if matched in the pattern, is NOT escaped when returned in the back-reference! stripslashes() ends up returning a null when only a single backslash is passed to it. If we can't change the behaviour of preg_replace() without breaking compatibility, then I suggest introducing a new function called something like preg_replace_ex() or preg_replace_binsafe() or something, which fixes the bug properly. The ideal bug fix would be for the back-reference to never escape any returned characters, since the input string fed to preg_replace() is NOT in an escaped context, and you should not mix escaped data with unescaped data. Previous Comments: [2007-02-09 17:37:51] [EMAIL PROTECTED] ok, so after talking with Andrei, we came up with the decision to document it rather than changin the behaviour (e.g. because of bug #5676). BTW, probably you'll want to consider using preg_replace_callback(). note to self: need to review again the escaped chars (at least NULL, single-quote and double-quote are) [2007-02-08 21:55:58] jfrim at idirect dot com Another reason why it would be best to return NULL and DOUBLE-QUOTE (0x00 and 0x22 respectively) in regular expression back-references WITHOUT being escaped: If this bug was fixed by escaping the backslash as well... ...The the context of the resulting output string would be a mix of escaped and non-escaped data. (Since the input string is non-escaped, but back-references are escaped.) This would make it impossible to safely un-escape without risk of data corruption. The only way to handle this would be to use the "e" modifier in the regular expression and embed stripslashes() into the replacement string. That's extra processing overhead, and basically makes the entire preg_replace() function useless without the "e" modifier. It also defeats any possible purposes as to why the back-references are escaped in the first place. Boo to this solution! Alternatively, if this bug was fixed by returning NULL and DOUBLE-QUOTE without being escaped... When using preg_replace, the resulting string will always be in a non-encoded context. If a slash-encoded string is ever desired, the entire thing can be wrapped in addslashes() by the user, without ever risking destroying the integrity of the data. [2007-02-08 19:59:04] jfrim at idirect dot com The following code demonstrates 0x00 and 0x22 being escaped, without 0x5C being escaped. It creates an 8-bit ASCII text output, with the character value (in DECIMAL) enclosed within braces (except for escaped chars, in which case it ends up as "92"), followed by the actual character, then a CRLF, for all 256 characters. Note how the backslash (0x5C, decimal 92) is NOT escaped, and contrary to what [EMAIL PROTECTED] posted, the single-quote (0x27, decimal 39) is NOT escaped either. (The double-quote (0x22, decimal 34) is escaped instead.) [2007-02-08 19:47:10] jfrim at idirect dot com I have verifed that along with 0x00 being escaped, 0x22 (the double-quote character) is also esc
[PHP-DOC] #40395 [Asn]: PCRE engine unable to output NULL characters
ID: 40395
Updated by: [EMAIL PROTECTED]
Reported By: jfrim at idirect dot com
Status: Assigned
-Bug Type: PCRE related
+Bug Type: Documentation problem
Operating System: *
PHP Version: *
-Assigned To: andrei
+Assigned To: nlopess
New Comment:
ok, so after talking with Andrei, we came up with the decision to
document it rather than changin the behaviour (e.g. because of bug
#5676).
BTW, probably you'll want to consider using preg_replace_callback().
note to self: need to review again the escaped chars (at least NULL,
single-quote and double-quote are)
Previous Comments:
[2007-02-08 21:55:58] jfrim at idirect dot com
Another reason why it would be best to return NULL and DOUBLE-QUOTE
(0x00 and 0x22 respectively) in regular expression back-references
WITHOUT being escaped:
If this bug was fixed by escaping the backslash as well...
...The the context of the resulting output string would be a mix of
escaped and non-escaped data. (Since the input string is non-escaped,
but back-references are escaped.) This would make it impossible to
safely un-escape without risk of data corruption. The only way to
handle this would be to use the "e" modifier in the regular expression
and embed stripslashes() into the replacement string. That's extra
processing overhead, and basically makes the entire preg_replace()
function useless without the "e" modifier. It also defeats any
possible purposes as to why the back-references are escaped in the
first place. Boo to this solution!
Alternatively, if this bug was fixed by returning NULL and DOUBLE-QUOTE
without being escaped...
When using preg_replace, the resulting string will always be in a
non-encoded context. If a slash-encoded string is ever desired, the
entire thing can be wrapped in addslashes() by the user, without ever
risking destroying the integrity of the data.
[2007-02-08 19:59:04] jfrim at idirect dot com
The following code demonstrates 0x00 and 0x22 being escaped, without
0x5C being escaped.
It creates an 8-bit ASCII text output, with the character value (in
DECIMAL) enclosed within braces (except for escaped chars, in which
case it ends up as "92"), followed by the actual character, then a
CRLF, for all 256 characters.
Note how the backslash (0x5C, decimal 92) is NOT escaped, and contrary
to what [EMAIL PROTECTED] posted, the single-quote (0x27, decimal 39) is
NOT escaped either. (The double-quote (0x22, decimal 34) is escaped
instead.)
[2007-02-08 19:47:10] jfrim at idirect dot com
I have verifed that along with 0x00 being escaped, 0x22 (the
double-quote character) is also escaped. No other byte values are
affected.
Even if the documentation was changed to reflect this escaped behaviour
of 0x00 and 0x22, there would still be a bug with this behaviour since
0x5C (the backslash character) is NOT escaped!
This would create a discrepency problem if the input string to a
preg_replace() contained a literal backslash followed by a number zero,
or a backslash followed by a double-quote. There would be no way to
tell from the resulting preg_replace'd data if those sequences are
escaped NULLs and escaped double-quotes, or if those were literal
sequences in the input string.
So the only way to fix this bug is to either...
...A: Escape the backslash as well, and change the documentation to
state that 0x00, 0x22, and 0x5C are escaped, or...
...B: Do not escape any characters.
I would say method B is preferred, since no stripslashes() would have
to be performed on the resulting output from a preg_replace(), and it's
far more intuitive to always know that a regular expression
back-reference will always contain the exact byte value that was
matched, without having to worry about special exceptions.
[2007-02-08 13:17:59] [EMAIL PROTECTED]
Ok, so the problem here is that preg_do_eval() calls
php_addslashes_ex(), that escapes "'", "\" and "\0".
So we should either not escape the \0 or reflect the behaviour in the
docs.
Assigning to the extension maintainer.
[2007-02-08 06:01:32] jfrim at idirect dot com
I'd also like to present bug #16590:
http://bugs.php.net/bug.php?id=16590
Note the following example they list as a SOLUTION to specifying NULLs
in the pattern:
preg_match("/\\x00/", "foo\0bar")
And note the following statement from bug report #16590:
"...The docs state that PCRE is binary safe..."
So if PCRE is binary safe, and you can specify NULLs in the pattern
with \x00, why are back references unable to return these matched
NULLs?!?!?
How is this NOT a bug?!??
--
[PHP-DOC] #40405 [Opn]: htmlentities example is incorrect.
ID: 40405 Updated by: [EMAIL PROTECTED] Reported By: ar3121 at att dot com Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Hmmm. The most recently built Windows CHM and Extended CHM files show this correctly. The CVS was last changed in 2003, so this means that the web building mechanism is at fault somewhere. But the page was last built in Dec 2006. It may need a rebuild. I'll try and get this done. Previous Comments: [2007-02-09 15:05:54] ar3121 at att dot com Look closer... the actual html you just posted does not match the example. Maybe it would help if you focused on just the second half of the example: bold"; // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> [2007-02-09 11:00:18] [EMAIL PROTECTED] If you run the code through a browser (I'm using FF on WinXP), then the screen shows ... A 'quote' is boldA 'quote' is bold But if you look at the actual HTML ... A 'quote' is boldA 'quote' is bold Which matches the example. [2007-02-09 10:57:54] [EMAIL PROTECTED] The example is correct. 09/02/2007 11:00:05 C:\>php -n bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> ^Z A 'quote' is boldA 'quote' is bold [2007-02-08 17:12:17] ar3121 at att dot com Description: On the htmlentities function documentation page: http://us2.php.net/htmlentities Example 2262 is incorrect. The function call with and without ENT_QUOTES produces different results, but the documentation says they're the same. Expected result: bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> Actual result: -- bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> -- Edit this bug report at http://bugs.php.net/?id=40405&edit=1
Re: [PHP-DOC] Execute permissions needed on chm/make_chm.bat
The only way to change the permissions is by manually doing it in the server. CC'ing our system admins for a 'chmod 755 /repository/phpdoc/chm/make_chm.bat' Thanks, Nuno - Original Message - From: "Richard A. Quadling" <[EMAIL PROTECTED]> To: Sent: Friday, February 09, 2007 4:23 PM Subject: [PHP-DOC] Execute permissions needed on chm/make_chm.bat Hi. The file /phpdoc/htmlhelp/make_chm.bat has permissions of 0755 which means that when using Cygwin to create the extended CHM file, the whole script can run within Cygwin. The file /phpdoc/chm/make_chm.bat has permissions of 0644 which means that when you run ... make chm you end up with ... [snip] chm/make_chm.bat en -D . make: execvp: chm/make_chm.bat: Permission denied make: *** [chm] Error 127 Manually chmoding the /phpdoc/chm/make_chm.bat to 0755 and then manually running ./chm/make_chm.bat works fine. As I've no idea how to set file permissions via cvs can someone do this for me? This will allow for me to help test anything that Hannes or anyone else does which affects the fancy CHM file. I've got the extended CHM file covered. Regards, Richard Quadling.
[PHP-DOC] cvs: phpdoc /en/reference/swish classes.xml /en/reference/swish/functions swish-getMetaList.xml swish-getPropertyList.xml swish-getmetalist.xml swish-getpropertylist.xml swishresult-getMeta
tony2001Fri Feb 9 16:57:06 2007 UTC Added files: /phpdoc/en/reference/swish/functionsswish-getmetalist.xml swish-getpropertylist.xml swishresult-getmetalist.xml swishresults-getparsedwords.xml swishresults-getremovedstopwords.xml swishresults-nextresult.xml swishresults-seekresult.xml swishsearch-resetlimit.xml swishsearch-setlimit.xml swishsearch-setphrasedelimiter.xml swishsearch-setsort.xml swishsearch-setstructure.xml Removed files: /phpdoc/en/reference/swish/functionsswish-getMetaList.xml swish-getPropertyList.xml swishresult-getMetaList.xml swishresults-getParsedWords.xml swishresults-getRemovedStopwords.xml swishresults-nextResult.xml swishresults-seekResult.xml swishsearch-resetLimit.xml swishsearch-setLimit.xml swishsearch-setPhraseDelimiter.xml swishsearch-setSort.xml swishsearch-setStructure.xml Modified files: /phpdoc/en/reference/swish classes.xml Log: use lowercase IDs and filenames http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/swish/classes.xml?r1=1.1&r2=1.2&diff_format=u Index: phpdoc/en/reference/swish/classes.xml diff -u phpdoc/en/reference/swish/classes.xml:1.1 phpdoc/en/reference/swish/classes.xml:1.2 --- phpdoc/en/reference/swish/classes.xml:1.1 Fri Feb 9 13:35:21 2007 +++ phpdoc/en/reference/swish/classes.xml Fri Feb 9 16:57:06 2007 @@ -1,5 +1,5 @@ - + &reftitle.classes; @@ -44,11 +44,11 @@ -- returns an array +- returns an array of meta entries for the given index file. -- returns an array +- returns an array of properties for the given index file. @@ -63,33 +63,33 @@ - - sets the + - sets the structure flag in the search object. This flag is used to limit search to certain parts of HTML documents. - - sets + - sets the phrase delimiter character. The default delimiter is double-quotes. - - sets the sort + - sets the sort order of the results. - - sets the limits + - sets the limits for the search. Throws SwishException on error. - - resets the + - resets the limits. @@ -128,14 +128,14 @@ - - returns + - returns next SwishResult object or &false; if no more results are available. - - sets the + - sets the current seek position in the SwishResults object. Throws SwishException on error. @@ -143,13 +143,13 @@ - - + - returns an array of words in the query with stopwords removed. - - + - returns an array of removed stopwords. @@ -173,7 +173,7 @@ - - returns + - returns an array of meta entries for the index used in this result. http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/swish/functions/swish-getmetalist.xml?view=markup&rev=1.1 Index: phpdoc/en/reference/swish/functions/swish-getmetalist.xml +++ phpdoc/en/reference/swish/functions/swish-getmetalist.xml Swish->getMetaList Get the list of meta entries for the index &reftitle.description; arraySwish->getMetaList stringindex_name &warn.experimental.func; &reftitle.parameters; index_name The name of the index file. &reftitle.returnvalues; Returns an array of meta entries for the given index.
[PHP-DOC] Execute permissions needed on chm/make_chm.bat
Hi. The file /phpdoc/htmlhelp/make_chm.bat has permissions of 0755 which means that when using Cygwin to create the extended CHM file, the whole script can run within Cygwin. The file /phpdoc/chm/make_chm.bat has permissions of 0644 which means that when you run ... make chm you end up with ... [snip] chm/make_chm.bat en -D . make: execvp: chm/make_chm.bat: Permission denied make: *** [chm] Error 127 Manually chmoding the /phpdoc/chm/make_chm.bat to 0755 and then manually running ./chm/make_chm.bat works fine. As I've no idea how to set file permissions via cvs can someone do this for me? This will allow for me to help test anything that Hannes or anyone else does which affects the fancy CHM file. I've got the extended CHM file covered. Regards, Richard Quadling.
[PHP-DOC] cvs: phpdoc / Makefile.in
rquadling Fri Feb 9 16:16:08 2007 UTC Modified files: /phpdoc Makefile.in Log: Removed unused, unworking, recently added as a test, chm_normal http://cvs.php.net/viewvc.cgi/phpdoc/Makefile.in?r1=1.186&r2=1.187&diff_format=u Index: phpdoc/Makefile.in diff -u phpdoc/Makefile.in:1.186 phpdoc/Makefile.in:1.187 --- phpdoc/Makefile.in:1.186Tue Feb 6 14:48:01 2007 +++ phpdoc/Makefile.in Fri Feb 9 16:16:07 2007 @@ -16,7 +16,7 @@ # # -# $Id: Makefile.in,v 1.186 2007/02/06 14:48:01 bjori Exp $ +# $Id: Makefile.in,v 1.187 2007/02/09 16:16:07 rquadling Exp $ # all: html @@ -280,10 +280,6 @@ chm: html FORCE chm/make_chm.bat $(LANG) -# RAQ : Monday, 5 February 2007 10:04 am : Build the normal chm rather than the fancy (make chm) or extended chm (make chm_xsl, htmlhtml/make_chm.bat, etc.) -chm_nonfancy: html FORCE - chm/make_chm.bat $(LANG) normal - # File endings we are going to define general rules for: .SUFFIXES: .html .xml .sgml .tex .dvi .ps .pdf .rtf .gz .bz2 .txt .PRECIOUS: %.html %.dvi
[PHP-DOC] cvs: phpdoc /en/appendices ini.xml
colder Fri Feb 9 15:56:07 2007 UTC Modified files: /phpdoc/en/appendices ini.xml Log: - there is no fopen_with_path function - complete the list of functions that supports include_path http://cvs.php.net/viewvc.cgi/phpdoc/en/appendices/ini.xml?r1=1.47&r2=1.48&diff_format=u Index: phpdoc/en/appendices/ini.xml diff -u phpdoc/en/appendices/ini.xml:1.47 phpdoc/en/appendices/ini.xml:1.48 --- phpdoc/en/appendices/ini.xml:1.47 Mon Feb 5 18:03:10 2007 +++ phpdoc/en/appendices/ini.xmlFri Feb 9 15:56:07 2007 @@ -1,5 +1,5 @@ - + &php.ini; directives @@ -3502,11 +3502,12 @@ Specifies a list of directories where the - require, include - and fopen_with_path functions look for - files. The format is like the system's PATH - environment variable: a list of directories separated with a - colon in Unix or semicolon in Windows. + require, include, + fopen, file, + readfile and file_get_contents + functions look for files. The format is like the system's + PATH environment variable: a list of directories + separated with a colon in Unix or semicolon in Windows.
[PHP-DOC] #40405 [Bgs->Opn]: htmlentities example is incorrect.
ID: 40405 User updated by: ar3121 at att dot com Reported By: ar3121 at att dot com -Status: Bogus +Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Look closer... the actual html you just posted does not match the example. Maybe it would help if you focused on just the second half of the example: bold"; // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> Previous Comments: [2007-02-09 11:00:18] [EMAIL PROTECTED] If you run the code through a browser (I'm using FF on WinXP), then the screen shows ... A 'quote' is boldA 'quote' is bold But if you look at the actual HTML ... A 'quote' is boldA 'quote' is bold Which matches the example. [2007-02-09 10:57:54] [EMAIL PROTECTED] The example is correct. 09/02/2007 11:00:05 C:\>php -n bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> ^Z A 'quote' is boldA 'quote' is bold [2007-02-08 17:12:17] ar3121 at att dot com Description: On the htmlentities function documentation page: http://us2.php.net/htmlentities Example 2262 is incorrect. The function call with and without ENT_QUOTES produces different results, but the documentation says they're the same. Expected result: bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> Actual result: -- bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> -- Edit this bug report at http://bugs.php.net/?id=40405&edit=1
[PHP-DOC] cvs: phpdoc /en/reference/sam/functions SAM-Connection-setdebug.xml
takagi Fri Feb 9 13:58:40 2007 UTC Modified files: /phpdoc/en/reference/sam/functions SAM-Connection-setdebug.xml Log: fixed $Revision$ tag. http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/sam/functions/SAM-Connection-setdebug.xml?r1=1.2&r2=1.3&diff_format=u Index: phpdoc/en/reference/sam/functions/SAM-Connection-setdebug.xml diff -u phpdoc/en/reference/sam/functions/SAM-Connection-setdebug.xml:1.2 phpdoc/en/reference/sam/functions/SAM-Connection-setdebug.xml:1.3 --- phpdoc/en/reference/sam/functions/SAM-Connection-setdebug.xml:1.2 Tue Feb 6 19:23:32 2007 +++ phpdoc/en/reference/sam/functions/SAM-Connection-setdebug.xml Fri Feb 9 13:58:40 2007 @@ -1,5 +1,5 @@ - + SAMConnection::setDebug()
[PHP-DOC] #40405 [Bgs]: htmlentities example is incorrect.
ID: 40405 Updated by: [EMAIL PROTECTED] Reported By: ar3121 at att dot com Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: If you run the code through a browser (I'm using FF on WinXP), then the screen shows ... A 'quote' is boldA 'quote' is bold But if you look at the actual HTML ... A 'quote' is boldA 'quote' is bold Which matches the example. Previous Comments: [2007-02-09 10:57:54] [EMAIL PROTECTED] The example is correct. 09/02/2007 11:00:05 C:\>php -n bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> ^Z A 'quote' is boldA 'quote' is bold [2007-02-08 17:12:17] ar3121 at att dot com Description: On the htmlentities function documentation page: http://us2.php.net/htmlentities Example 2262 is incorrect. The function call with and without ENT_QUOTES produces different results, but the documentation says they're the same. Expected result: bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> Actual result: -- bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> -- Edit this bug report at http://bugs.php.net/?id=40405&edit=1
[PHP-DOC] #40405 [Opn->Bgs]: htmlentities example is incorrect.
ID: 40405 Updated by: [EMAIL PROTECTED] Reported By: ar3121 at att dot com -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: The example is correct. 09/02/2007 11:00:05 C:\>php -n bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> ^Z A 'quote' is boldA 'quote' is bold Previous Comments: [2007-02-08 17:12:17] ar3121 at att dot com Description: On the htmlentities function documentation page: http://us2.php.net/htmlentities Example 2262 is incorrect. The function call with and without ENT_QUOTES produces different results, but the documentation says they're the same. Expected result: bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> Actual result: -- bold"; // Outputs: A 'quote' is bold echo htmlentities($str); // Outputs: A 'quote' is bold echo htmlentities($str, ENT_QUOTES); ?> -- Edit this bug report at http://bugs.php.net/?id=40405&edit=1
