[PHP-DOC] #13321 [Opn->Csd]: Documnetation
ID: 13321 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Win 32 PHP Version: 4.0.6 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-03-11 02:17:51] [EMAIL PROTECTED] Nice ;) Who will volunteer to find this out? Goba [2002-03-09 00:22:18] [EMAIL PROTECTED] Filesystem functions that contain the &no-windows; entity are as follows: chgrp, chmod, chown, filegroup, fileinode, fileowner, is_link, link, linkinfo, readlink, symlink, umask The question is, which work now and when did they begin to work? And to go beyond this bug, how about making available a list of all win32/linux "differences", in relation to PHP. There are a few, like slashes, \newlines, various functions, sendmail_from directive, etc. [2002-03-09 00:00:01] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-02-06 12:13:56] [EMAIL PROTECTED] Examples? More info needed than that! [2001-09-15 13:11:45] [EMAIL PROTECTED] Many of the file function in the manual now works on Win32 Sure you know that, but the manual is not updated. -- Edit this bug report at http://bugs.php.net/?id=13321&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/filesystem/functions chgrp.xml chmod.xml chown.xml filegroup.xml fileinode.xml fileowner.xml is-link.xml link.xml linkinfo.xml readlink.xml symlink.xml umask.xml
kalowskyTue Aug 13 23:28:02 2002 EDT Modified files: /phpdoc/en/reference/filesystem/functions chgrp.xml chmod.xml chown.xml filegroup.xml fileinode.xml fileowner.xml is-link.xml link.xml linkinfo.xml readlink.xml symlink.xml umask.xml Log: Closing Bug #13321 Index: phpdoc/en/reference/filesystem/functions/chgrp.xml diff -u phpdoc/en/reference/filesystem/functions/chgrp.xml:1.2 phpdoc/en/reference/filesystem/functions/chgrp.xml:1.3 --- phpdoc/en/reference/filesystem/functions/chgrp.xml:1.2 Wed Apr 17 02:38:05 2002 +++ phpdoc/en/reference/filesystem/functions/chgrp.xml Tue Aug 13 23:28:02 2002 @@ -1,5 +1,5 @@ - + @@ -26,7 +26,6 @@ See also chown and chmod. -¬e.no-windows; Index: phpdoc/en/reference/filesystem/functions/chmod.xml diff -u phpdoc/en/reference/filesystem/functions/chmod.xml:1.2 phpdoc/en/reference/filesystem/functions/chmod.xml:1.3 --- phpdoc/en/reference/filesystem/functions/chmod.xml:1.2 Wed Apr 17 02:38:05 2002 +++ phpdoc/en/reference/filesystem/functions/chmod.xml Tue Aug 13 23:28:02 2002 @@ -1,5 +1,5 @@ - + @@ -40,7 +40,6 @@ See also chown and chgrp. -¬e.no-windows; Index: phpdoc/en/reference/filesystem/functions/chown.xml diff -u phpdoc/en/reference/filesystem/functions/chown.xml:1.3 phpdoc/en/reference/filesystem/functions/chown.xml:1.4 --- phpdoc/en/reference/filesystem/functions/chown.xml:1.3 Thu Aug 8 14:26:01 2002 +++ phpdoc/en/reference/filesystem/functions/chown.xml Tue Aug 13 23:28:02 2002 @@ -1,5 +1,5 @@ - + @@ -24,7 +24,6 @@ See also chmod. -¬e.no-windows; Index: phpdoc/en/reference/filesystem/functions/filegroup.xml diff -u phpdoc/en/reference/filesystem/functions/filegroup.xml:1.2 phpdoc/en/reference/filesystem/functions/filegroup.xml:1.3 --- phpdoc/en/reference/filesystem/functions/filegroup.xml:1.2 Wed Apr 17 02:38:07 2002 +++ phpdoc/en/reference/filesystem/functions/filegroup.xml Tue Aug 13 23:28:02 +2002 @@ -1,5 +1,5 @@ - + @@ -21,7 +21,6 @@ The results of this function are cached. See clearstatcache for more details. -¬e.no-windows; This function will not work on - + @@ -24,7 +24,6 @@ linkend="features.remote-files">remote files; the file to be examined must be accessible via the server's filesystem. -¬e.no-windows; Index: phpdoc/en/reference/filesystem/functions/fileowner.xml diff -u phpdoc/en/reference/filesystem/functions/fileowner.xml:1.2 phpdoc/en/reference/filesystem/functions/fileowner.xml:1.3 --- phpdoc/en/reference/filesystem/functions/fileowner.xml:1.2 Wed Apr 17 02:38:07 2002 +++ phpdoc/en/reference/filesystem/functions/fileowner.xml Tue Aug 13 23:28:02 +2002 @@ -1,5 +1,5 @@ - + @@ -26,7 +26,6 @@ linkend="features.remote-files">remote files; the file to be examined must be accessible via the server's filesystem. -¬e.no-windows; Index: phpdoc/en/reference/filesystem/functions/is-link.xml diff -u phpdoc/en/reference/filesystem/functions/is-link.xml:1.2 phpdoc/en/reference/filesystem/functions/is-link.xml:1.3 --- phpdoc/en/reference/filesystem/functions/is-link.xml:1.2Wed Apr 17 02:38:08 2002 +++ phpdoc/en/reference/filesystem/functions/is-link.xmlTue Aug 13 23:28:02 +2002 @@ -1,5 +1,5 @@ - + @@ -28,7 +28,6 @@ linkend="features.remote-files">remote files; the file to be examined must be accessible via the server's filesystem. -¬e.no-windows; Index: phpdoc/en/reference/filesystem/functions/link.xml diff -u phpdoc/en/reference/filesystem/functions/link.xml:1.2 phpdoc/en/reference/filesystem/functions/link.xml:1.3 --- phpdoc/en/reference/filesystem/functions/link.xml:1.2 Wed Apr 17 02:38:09 2002 +++ phpdoc/en/reference/filesystem/functions/link.xml Tue Aug 13 23:28:02 2002 @@ -1,5 +1,5 @@ - + @@ -20,7 +20,6 @@ and readlink along with linkinfo. -¬e.no-windows; Index: phpdoc/en/reference/filesystem/functions/linkinfo.xml diff -u phpdoc/en/reference/filesystem/functions/linkinfo.xml:1.2 phpdoc/en/reference/filesystem/functions/linkinfo.xml:1.3 --- phpdoc/en/reference/filesystem/functions/linkinfo.xml:1.2 Wed Apr 17 02:38:09 2002 +++ phpdoc/en/reference/filesystem/functions/linkinfo.xml Tue Aug 13 23:28:02 +2002 @@ -1,5 +1,5 @@ - + @@ -24,7 +24,6 @@ See also symlink, link, and readlink. -¬e.no-windows; Index: phpdoc/en/reference/filesystem/
[PHP-DOC] #11618 [Ana->Csd]: session and form data
ID: 11618 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Documentation problem Operating System: linux 2.2.16-22 PHP Version: 4.0.4 New Comment: Sorry, but the bug system is not the appropriate forum for asking support questions. Your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Thank you for your interest in PHP. The manual now contains clear exmaples of headers that should be sent to prevent caching of both HTTP/1.0 and HTTP/1.1 connections. Previous Comments: [2002-02-08 08:33:13] [EMAIL PROTECTED] Ok. Try telnetting to that page "telnet yoursite.com 80" Type: HEAD /thepage.php HTTP/1.1 Host: yoursite.com Obviously replace thepage.php and yoursite.com with your actual site. See what the headers are (especially the "Pragma:" or "Cache-Control" headers) [2002-02-07 22:41:59] [EMAIL PROTECTED] To answer the most recent question from alindeman (I apologize, but I do not know your name): The mention of nocache isn't exactly just HTTP/1.0, however the Pragma header in fact is unique to HTTP/1.0 and was only included in HTTP/1.1 to maintain backwards compatibility. No directives exist for this header except nocache. HTTP/1.1 introduces the Cache-Control header, and with it comes many available directives. In fact, nocache is still one of these. I'm honestly not sure how the session_cache_limiter is implemented at the protocol level, but I can try to figure it out if it would be helpful to you. guo_feng: Though from your brief account I would say that you have now chosen the most appropriate value for session_cache_limiter (assuming it affects the value of the Cache-Control header), I would suggest learning more about it so that you feel more confident in your implementation. To briefly answer your question, however, public basically declares that the content may be cached by anything. Private has a bit more unclear definition to me (you might find more clarification in your research), but it basically allows caching but not in a shared cache. An example of a shared cache would be a proxy that many people are connected to, so the content might be considered a bit too sensitive to be accidentally returned to another user. Hope that helps. Thanks for all your help guo_feng. Chris [2002-02-07 19:33:35] [EMAIL PROTECTED] Wasn't "nocache" a HTTP/1.0 thing? Is "must-revalidate" the HTTP/1.1 equivilant? Can anybody verify this so that I can do something with the docs. [2001-06-23 06:35:20] [EMAIL PROTECTED] reclassified as documentation problem. This should be explained better in the manual. [2001-06-22 12:57:37] [EMAIL PROTECTED] I have solve the problem when I set session.cache_limiter =must-revalidate But I don't why!Can somebody tell me? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/11618 -- Edit this bug report at http://bugs.php.net/?id=11618&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #10374 [Opn->Bgs]: Depreciated features or not
ID: 10374 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: 4.0.4pl1 New Comment: Sorry, but the bug system is not the appropriate forum for asking support questions. Your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Thank you for your interest in PHP. There are no set dates or release numbers for when legacy function will be removed. As far as I know PHP4 still supports many functions that were marked as legacy back in 3.X days. If/When a function will be removed be assured it will be noted in the release notes for that version. Previous Comments: [2001-04-18 03:39:37] [EMAIL PROTECTED] There are features/functions that are depreciated or going to be depreciated. It is nice to see what is depreciated and is going to be depreciated in the PHP Manual. (Although, there is "Migrating from " section. List of them would be nice and some of them is not docuemented. There aren't many as far as I know especially after 4.0.0.) I guess depreciated feature/function/etc are not on the manual, but it hard to tell w/o document if they are just not documented or depreciated and deleted. It would be also nice to encourage/discourage use of feature/function/etc for current/future release. Examples are: - accessing string as array and modify string as array - (It's in NEWS and user could know it's depreciated, though) - set_nonblock() - Assoc array index without quote. For example, $str = "This is $arr[element] and you will NOT see warning with E_ALL and this works"; - track_vars always on for 4.0.3(It's in NEWS, though) - magic_quote = off in php.ini for 4.1? -- Edit this bug report at http://bugs.php.net/?id=10374&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] $AUTHOR$ -> $Author$ ??
Yeah, the $Author$ here is the cvs username of the last modifier of the file. In this way we can get to know who modified the file at last time. We just inheret this behavior from the Italian and Japenese Molude, and correct it to make it work. Greg "Gabor Hojtsy" <[EMAIL PROTECTED]> wrote in message 01fd01c242db$bad1fc30$5a37a3d5@mia">news:01fd01c242db$bad1fc30$5a37a3d5@mia... > > Well, no file in the en tree is using $Author$ comments, but many > > translation molude such as Italian and Japenese Translation as well as the > > Chinese Molude is using the comment lines as following in every xml file: > > > > > > > > > > > > > > However, you may find the second line above of the xml files in Italian or > > Japenese molude are: > > > > > > > > It's not available for cvs to replace it correctly... > > So it's not in the howto, because it was not used widely when > the howto's translation section was assemmbled. BTW what's the point > in using that comment, can you please explain me? As you have a > maintainer info in the translation comment and have a list of previous > maintainers in the credits list, why you need to have an $Author? > Which is even not the name of the person, who is the author, but > who last modified the document isn't it? > > Goba > > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18798 [Opn->Csd]: Mail doesn't sent to "Mary " this format
ID: 18798 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Windows 2k Server SP2 PHP Version: 4.3.0-dev New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-08-11 08:15:25] [EMAIL PROTECTED] This is a limitation of the mail() command. Adresses in the form of "Something <[EMAIL PROTECTED]>" are NOT support by the mail() command. The technical issue is that mail() does not parsing and while tlaking to the MTA it simple puts the email addresse in '<' and '>' brackets which will then look something like ">" which of course doesn't work. You have a two options to me knowledge: 1) trim down the $to field to the [EMAIL PROTECTED] part and use the From: custom header 2) Try if the imap_mail() command works for you, afaik it does email address parsing. Reclassifying as documentation problem for mail() on win32. The page should also mention imap_mail(). [2002-08-08 08:33:11] [EMAIL PROTECTED] The problem remains I installed the latest snap: - php4-win32-latest.zip - 08-Aug-2002 03:26 5.3M If you like I can give you ftp-access to the server. Then you can try the mail routine yourself. [2002-08-08 08:25:40] [EMAIL PROTECTED] Sorry, should have said that earlier: please try a _non_ STABLE snapshot. [2002-08-08 08:05:11] [EMAIL PROTECTED] I installed the snap (php4-win32-STABLE-latest.zip - 08-Aug-2002 01:23 4.6M), but the problem remain. [2002-08-08 06:15:01] [EMAIL PROTECTED] Can you test the latest snapshot from http://snaps.php.net, this might have been fixed. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18798 -- Edit this bug report at http://bugs.php.net/?id=18798&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/mail/functions mail.xml
kalowskyTue Aug 13 20:27:00 2002 EDT Modified files: /phpdoc/en/reference/mail/functions mail.xml Log: Additional documentation for bug #18798 Index: phpdoc/en/reference/mail/functions/mail.xml diff -u phpdoc/en/reference/mail/functions/mail.xml:1.8 phpdoc/en/reference/mail/functions/mail.xml:1.9 --- phpdoc/en/reference/mail/functions/mail.xml:1.8 Sun May 19 12:12:35 2002 +++ phpdoc/en/reference/mail/functions/mail.xml Tue Aug 13 20:27:00 2002 @@ -1,5 +1,5 @@ - + @@ -178,6 +178,17 @@ or the mail may not be sent properly. + + + The to parameter cannot be an address + in the form of "Something <[EMAIL PROTECTED]>". The + mail command will not parse this properly while talking with + the MTA. + + + + See also imap_mail. + -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] php_error_docref
It's needed because a lot of the doc pages are long, and there is not always going to be a 1:1 mapping between the active function and a description of the error. For example, in the stream wrappers, when someone tries to open an http connection for write, or tries to overwrite an existing file via ftp, we will want to inform the user that we don't support this action. Now, if fopen was the only function that createdwrappers, we could use a NULL for the docref. In actual fact fopen(), copy(), and other extensions will all be using wrappers, so the active function becomes meaningless. Couple that with the main description of using URLs not actually being on the fopen manual page (it's under features.remote-files), and because that page is really long, finding the two lines that say you can't do that is pretty hard work. So, we do need the '#target' syntax in there :-) --Wez. On 08/13/02, "Dan Kalowsky" <[EMAIL PROTECTED]> wrote: > > NULL or "#" is best here since it allows the phpdoc group to change > > their mind for naming the pages. > > Then again, I don't understand what this parameter is for. If not for the > developer to declare which help file this is in, what is the point? Yes I > see the anchor tags option, but what is the difference between using an > anchor and declaring specifically? > > It just seems that if this variable is going to be 90% of the time (random > guess) NULL, it's not really all the necessary to be included. -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] developers manual and users manual
--- Gabor Hojtsy <[EMAIL PROTECTED]> wrote: > > May I suggest you just duplicate the entire > current manual structures for > > the new manual(s) and don't add any translation > directories. That way > when > > someone decides they have to have the new manual > in their native language > > you don't have to work so hard to support it. > They will eventually... > > Uh, it's not that easy. We have separate mailing > lists for translations > and separate CVS modules for every translation. > Well, if we duplicate all > these, we get a huge mess... If we push all users > manual content one subdir > down and make a new subdir for developers manual > content (in all phpdoc > modules), then we get a huge mess (there will be no > CVS history for files, > updates will get even harder). Yep, It might be simpler to move the chapters/appendices that will make the "Devloper's manual" (or whatever name we decide) to its own top level CVS dir tree, and then handle that part alone. As that is the (relatively) newer part of the current manual, it will generate the less amount of damage/problems. Now, separating the rest into a Language and a Function references will be hairier and short of splitting them and then hand-fixing the CVS files, I have no simple ideas/solutions to propose. > Actually I don't > think so that someone can > write a PHP extension if he even don't know > English... Agree there. If we separate the "Howto", Zend engine, streams, etc. into its own 'phpdoc-dev' (or something like that), then it will be clear that is not something to be translated. > PEAR, PHP-GTK, TSRM and other projects also copied > the build system, so we > have quite differently evolved build systems > everywhere. Copying the build > system does not help IMHO, but increases confusion, > as different projects > modify that initially same build system to their > needs in different ways, > so you cannot just jump in and work with another > build system. Indeed, in particular in PEAR we are working towards allowing simpler generation of class documentations. As we are already using javadoc-style comments in the code, we could generate the DocBook prototypes programatically, the PEAR::PHPDoc tool is being modified for that purpose. Also there are some OpenOffice -> DocBook filters being developed to simplify the task of writing the tutorials on how to use the packages, etc. > For example the PEAR system uses XSL sheets > exclusively, while we are just > in the testing phase of converting to XSL sheets, > and still use DSSSL ones, > which require completely different conversion > tools... > > Goba = --- Jesus M. Castagnetto <[EMAIL PROTECTED]> __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18889 [Opn->Csd]: SID constant listed as integer in PHP session documentation.
ID: 18889 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.2.2 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. Corrected in the docs. it will appear in the next build. Previous Comments: [2002-08-13 16:26:49] [EMAIL PROTECTED] http://www.php.net/manual/en/ref.session.php SID (integer) Constant containing the session name and session ID in the form of "name=ID". Obviously an integer cannot contain the string "name=", The id itself isn't an integer, either, so obviously it was mislabeled. It should be listed as a string. -- Edit this bug report at http://bugs.php.net/?id=18889&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/session constants.xml
damsTue Aug 13 18:55:40 2002 EDT Modified files: /phpdoc/en/reference/sessionconstants.xml Log: SID is a string Index: phpdoc/en/reference/session/constants.xml diff -u phpdoc/en/reference/session/constants.xml:1.1 phpdoc/en/reference/session/constants.xml:1.2 --- phpdoc/en/reference/session/constants.xml:1.1 Sun Jul 28 10:04:32 2002 +++ phpdoc/en/reference/session/constants.xml Tue Aug 13 18:55:40 2002 @@ -1,5 +1,5 @@ - + &reftitle.constants; &extension.constants; @@ -7,7 +7,7 @@ SID -(integer) +(string) -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] php_error_docref
At 22:22 13.08.2002, 'Ricky' S Dhatt wrote:
>On Tue, 13 Aug 2002, Dan Kalowsky wrote:
>
> > On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
> >
> > > The point is to be able to direct to external sites not on php.net! For
> > > example
> > > when a function is just a wrapper around a library then you can use the
> > > absolute
> > > form of the docref parameter ("http://") to point to the library's
> > > website.
> >
> > Okay thats a point I hadn't thought of. Though I'm not sure why we'd be
> > referencing outside sites. Can we then change the CODING_STANDARD
> > example to NOT use the php.net website? Hopefully stopping anyone from
> > using it as a reference to any php-specific documentation, and only for
> > external sites.
>
>Do you think this will help the lost PHP script writer? For example, the
>cURL extension is really just a wrapper around libcurl. If they get an
>error on curl_setopt() do you really want to direct them to the C API
>docs on the cURL site? I think it should always point to the php.net
>manual; external sites won't help the PHP script writer with their PHP
>code. From the PHP manual they can go to library website if need be.
I thought of situations where an external document explains a standard that
must be used. For example when a database extension can deliver any url
describing the query error you can use php_error_docref() to point to that
page.
It is no solution for cURL where only C library or a standard exists as
external
URLs.
regards
marcus
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] php_error_docref
At 22:04 13.08.2002, Dan Kalowsky wrote:
>On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
>
> > The point is to be able to direct to external sites not on php.net! For
> > example
> > when a function is just a wrapper around a library then you can use the
> > absolute
> > form of the docref parameter ("http://") to point to the library's
> > website.
>
>Okay thats a point I hadn't thought of. Though I'm not sure why we'd be
>referencing outside sites. Can we then change the CODING_STANDARD
>example to NOT use the php.net website? Hopefully stopping anyone from
>using it as a reference to any php-specific documentation, and only for
>external sites.
>
> > NULL or "#" is best here since it allows the phpdoc group to change
> > their mind for naming the pages.
>
>Then again, I don't understand what this parameter is for. If not for the
>developer to declare which help file this is in, what is the point? Yes I
>see the anchor tags option, but what is the difference between using an
>anchor and declaring specifically?
It is there for directing to one specific page. For example i am going to
write the
common errors for exif only on the exif_read_data page. So i must set docref
parameter of all calls to php_error_docref() within exif to
exif-read-data#error.
Another problem is that you can direct to configuration pages and so on if the
error coccured due to a missconfiguration.
>It just seems that if this variable is going to be 90% of the time (random
>guess) NULL, it's not really all the necessary to be included.
It was intended to be the right parameter for abot 95%.
>And judging from the comment by Gabor, the PHPDOC group isn't going to
>change this format anytime soon.
I hoped so :-)
marcus
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18889 [NEW]: SID constant listed as integer in PHP session documentation.
From: [EMAIL PROTECTED] Operating system: PHP version: 4.2.2 PHP Bug Type: Documentation problem Bug description: SID constant listed as integer in PHP session documentation. http://www.php.net/manual/en/ref.session.php SID (integer) Constant containing the session name and session ID in the form of "name=ID". Obviously an integer cannot contain the string "name=", The id itself isn't an integer, either, so obviously it was mislabeled. It should be listed as a string. -- Edit bug report at http://bugs.php.net/?id=18889&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=18889&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=18889&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=18889&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=18889&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=18889&r=support Expected behavior: http://bugs.php.net/fix.php?id=18889&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=18889&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=18889&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=18889&r=globals -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] php_error_docref
On Tue, 13 Aug 2002, Dan Kalowsky wrote:
> On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
>
> > The point is to be able to direct to external sites not on php.net! For
> > example
> > when a function is just a wrapper around a library then you can use the
> > absolute
> > form of the docref parameter ("http://") to point to the library's
> > website.
>
> Okay thats a point I hadn't thought of. Though I'm not sure why we'd be
> referencing outside sites. Can we then change the CODING_STANDARD
> example to NOT use the php.net website? Hopefully stopping anyone from
> using it as a reference to any php-specific documentation, and only for
> external sites.
Do you think this will help the lost PHP script writer? For example, the
cURL extension is really just a wrapper around libcurl. If they get an
error on curl_setopt() do you really want to direct them to the C API
docs on the cURL site? I think it should always point to the php.net
manual; external sites won't help the PHP script writer with their PHP
code. From the PHP manual they can go to library website if need be.
My $.02.
--Ricky
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18888 [Csd->Dup]: tar.bz2 and tar.gz for binary releases
ID: 1 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Duplicate Bug Type: Documentation problem Operating System: win32 PHP Version: 4.2.2 New Comment: marking as duplicate, as it's not really closed yet. Previous Comments: [2002-08-13 15:23:28] [EMAIL PROTECTED] We are aware, see bug #18849. So closing. Friedhelm [2002-08-13 14:45:45] [EMAIL PROTECTED] The English Windows help file (chm) for download (dated Aug 9) has zero length. -- Edit this bug report at http://bugs.php.net/?id=1&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] php_error_docref
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
> The point is to be able to direct to external sites not on php.net! For
> example
> when a function is just a wrapper around a library then you can use the
> absolute
> form of the docref parameter ("http://") to point to the library's
> website.
Okay thats a point I hadn't thought of. Though I'm not sure why we'd be
referencing outside sites. Can we then change the CODING_STANDARD
example to NOT use the php.net website? Hopefully stopping anyone from
using it as a reference to any php-specific documentation, and only for
external sites.
> NULL or "#" is best here since it allows the phpdoc group to change
> their mind for naming the pages.
Then again, I don't understand what this parameter is for. If not for the
developer to declare which help file this is in, what is the point? Yes I
see the anchor tags option, but what is the difference between using an
anchor and declaring specifically?
It just seems that if this variable is going to be 90% of the time (random
guess) NULL, it's not really all the necessary to be included.
And judging from the comment by Gabor, the PHPDOC group isn't going to
change this format anytime soon.
>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/functions domxml.xml
maxim Tue Aug 13 16:04:10 2002 EDT Modified files: /phpdoc/en/functionsdomxml.xml Log: Switch places method arguments list as was notified by a user (PHP-NOTE# 24336) was doc typo. Index: phpdoc/en/functions/domxml.xml diff -u phpdoc/en/functions/domxml.xml:1.43 phpdoc/en/functions/domxml.xml:1.44 --- phpdoc/en/functions/domxml.xml:1.43 Wed Jun 19 01:31:05 2002 +++ phpdoc/en/functions/domxml.xml Tue Aug 13 16:04:10 2002 @@ -8,7 +8,7 @@ instead --> - + DOM XML functions DOM XML @@ -2411,8 +2411,8 @@ Description objectDomNode->replace_child - objectoldchild objectnewchild + objectoldchild This functions replace a child from a list of children. If the child cannot -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18888 [Opn->Csd]: tar.bz2 and tar.gz for binary releases
ID: 1 Updated by: [EMAIL PROTECTED] -Summary: Zero length chm file -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem -Operating System: Windows +Operating System: win32 PHP Version: 4.2.2 New Comment: We are aware, see bug #18849. So closing. Friedhelm Previous Comments: [2002-08-13 14:45:45] [EMAIL PROTECTED] The English Windows help file (chm) for download (dated Aug 9) has zero length. -- Edit this bug report at http://bugs.php.net/?id=1&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18888 [NEW]: Zero length chm file
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.2.2 PHP Bug Type: Documentation problem Bug description: Zero length chm file The English Windows help file (chm) for download (dated Aug 9) has zero length. -- Edit bug report at http://bugs.php.net/?id=1&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=1&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=1&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=1&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=1&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=1&r=support Expected behavior: http://bugs.php.net/fix.php?id=1&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=1&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=1&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=1&r=globals -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /howto howto.html.tar.gz tools.xml
gobaTue Aug 13 12:23:49 2002 EDT Modified files: /phpdoc/howto howto.html.tar.gz tools.xml Log: As we have XSL sheets bundeld, modify docs to reflect this, and adding more info on xsltproc usage. Index: phpdoc/howto/howto.html.tar.gz Index: phpdoc/howto/tools.xml diff -u phpdoc/howto/tools.xml:1.13 phpdoc/howto/tools.xml:1.14 --- phpdoc/howto/tools.xml:1.13 Sun Jul 28 05:47:34 2002 +++ phpdoc/howto/tools.xml Tue Aug 13 12:23:49 2002 @@ -310,41 +310,13 @@ CVS section of this document. - - - If you decide to use another directory in one of the next - steps, you'll probably need to modify - phpdoc/configure.in manually. - We do not give any support if you are self-opinionated :) - In this situation you can specify the DSSSL location - manually by using the - --with-dsssl=C:/path/to/dsssl - option with configure. - - - Make sure that you are in the directory where the phpdoc dir is located. (if you type ls, you should see - phpdoc listed). - - - - Type mkdir phpdoc-tools, and then unzip: - - - Jade to phpdoc-tools/jade - - - XSL stylesheets are not necessary - to generate the html versions of the manual, the DSSSL style - sheets are used by default (from - phpdoc/dsssl/docbook). If you think - you would like to test XSL ones, than unzip Norman Walsh's - XSL files to phpdoc-tools/xsl/docbook. See - &url.nwalsh.xsl; - for more information and downloadable files. + phpdoc listed). Type mkdir + phpdoc-tools, and then unzip Jade to + phpdoc-tools/jade. @@ -383,10 +355,6 @@ | | | \--jade.exe (etc) | - +--xsl (OPTIONAL!) - | | - | \--docbook (etc) - | \--php.bat @@ -424,9 +392,8 @@ In order to successfully use the XSL stylesheets -you must have some XSLT processor and the XSL -DocBook Stylesheets. This is sufficient for -generating HTML version of the documentation. +you must have some XSLT processor. This is sufficient +for generating HTML version of the documentation. If you also want to create a version suitable for printing, you will additionally need a FO processor. @@ -451,11 +418,19 @@ but is a promising technology. You do not need to setup any tools mentioned here if you would not like to play with XSL stylesheets. However - we plan to use XSLT in the future for HTML + we plan to use XSL in the future for HTML generation, and possibly PDF generation, if we can manage to work out how to do it correctly. + + +The phpdoc Makefile has options to +generate files using the XSL sheets, but these are currently +experimental (and require xsltproc exclusively). After running +./configure you can run make +html_xsl to generate HTML files using XSL sheets. + XSLT processors: @@ -472,9 +447,11 @@ - Gnome LibXSLT: &url.xsl.libxslt;, - also available as Windows binary: + Gnome LibXSLT (also known as xsltproc): + &url.xsl.libxslt;, + available as Windows binary too at: &url.xsl.libxslt.win;, + and also included in current cygwin setups. @@ -488,10 +465,6 @@ - -XSL DocBook Stylesheets: &url.xsl.style; - - FO processors: -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc / configure.in
gobaTue Aug 13 12:09:45 2002 EDT Modified files: /phpdoc configure.in Log: So now we have bundled XSL sheets, no need to check for system specific paths. With this the system should work "out of the box" with XSL sheets. Just run ./configure make html_xsl and the HTML files will be created with XSL sheets if xsltproc is found. If not, then you should specify the --with-xsltproc=PATH parameter. Cygwin has xsltproc, and most linux distributions today also has it... Index: phpdoc/configure.in diff -u phpdoc/configure.in:1.173 phpdoc/configure.in:1.174 --- phpdoc/configure.in:1.173 Sun Aug 11 14:19:07 2002 +++ phpdoc/configure.in Tue Aug 13 12:09:45 2002 @@ -1,4 +1,4 @@ -dnl $Id: configure.in,v 1.173 2002/08/11 18:19:07 wez Exp $ +dnl $Id: configure.in,v 1.174 2002/08/13 16:09:45 goba Exp $ dnl autoconf initialisation AC_INIT() @@ -241,9 +241,7 @@ DOCBOOKXSL_USED=yes AC_MSG_RESULT([in $withval (XSL path values on)]) else -# these path values are relative to the xsl directory -# of phpdoc (note that this directory is not in CVS, but -# it will be there if tests goes well) +# these path values are relative to the xsl directory! if test "$withval" = "yes"; then DOCBOOKXSL_BIGHTML="./docbook/html/docbook.xsl" DOCBOOKXSL_HTML="./docbook/html/chunk.xsl" @@ -252,30 +250,17 @@ AC_MSG_RESULT([in $srcdir/xsl/docbook (XSL path values on)]) else DOCBOOKXSL_USED=no + AC_MSG_RESULT([not found (XSL path values off)]) fi fi ],[ + # these path values are relative to the xsl directory! + DOCBOOKXSL_BIGHTML="./docbook/html/docbook.xsl" + DOCBOOKXSL_HTML="./docbook/html/chunk.xsl" + DOCBOOKXSL_PRINT="./docbook/fo/docbook.xsl" DOCBOOKXSL_USED=no - for dir in \ -$srcdir/xsl/docbook \ -$srcdir/phpdoc-tools/xsl \ -$srcdir/phpdoc-tools/xsl/docbook \ -$srcdir/../phpdoc-tools/xsl \ -$srcdir/../phpdoc-tools/xsl/docbook \ -/usr/share/sgml/docbkxsl -do -if test -f "$dir/html/docbook.xsl"; then -DOCBOOKXSL_BIGHTML=$dir/html/docbook.xsl -DOCBOOKXSL_HTML=$dir/html/chunk.xsl -DOCBOOKXSL_PRINT=$dir/fo/docbook.xsl -AC_MSG_RESULT([autodetected: $dir (XSL path values off)]) -break -fi - done + AC_MSG_RESULT([in $srcdir/xsl/docbook (XSL path values off)]) ]) -if test -z "$DOCBOOKXSL_BIGHTML"; then -AC_MSG_RESULT([not found (XSL path values off)]) -fi AC_SUBST(DOCBOOKXSL_BIGHTML) AC_SUBST(DOCBOOKXSL_HTML) AC_SUBST(DOCBOOKXSL_PRINT) -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /xsl/docbook BUGS PHPDOC-NOTE README VERSION
gobaTue Aug 13 11:34:28 2002 EDT Added files: /phpdoc/xsl/docbook BUGS PHPDOC-NOTE README VERSION Log: Adding XSL sheet 1.51.1 distribution (compatible with our customizations) -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] Re: [PHP-DEV] php_error_docref
>php_error_docref("function.fopen" TSRMLS_CC, E_WARNING, "Spongebob Square
>Pants lives in a pineapple under the sea");
>
>To me that should be the recommended method, as it will allow the php.ini
>values for language to override everything nicely, and everyone can see
>the PHP manual in their desired language. The error of course is still in
>English but thats another matter.
| NULL or "#" is best here since it allows the phpdoc group to
| change their mind for naming the pages.
It's not likely that this naming scheme will change. Internal linking,
php.net/funcname lookups, IDE integrations all depend on this naming
scheme...
Goba
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] php_error_docref
At 17:05 13.08.2002, Dan Kalowsky wrote:
>On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
>
> > >2) Can we please remove the "http://www.php.net/manual/en/blahblahblah";
> > >style of use for this? It will tend to force users into one language or
> > >another, and not make PHP as friendly/usable to other languages.
> >
> > NO! First you can simply set docref_root in your ini to point to your local
> > copy of the manual in whatever language and Second it is a problem of
> > the php website. It should automatically redirect from
> > php.net/function.
> > to php.net/manual//.php
>
>I'm not sure I see the point still. What I'm proposing is not allowing:
>
>php_error_docref("http://www.php.net/manual/en/function.fopen"; TSRMLS_CC,
>E_WARNING, "Spongebob Square Pants rules");
The point is to be able to direct to external sites not on php.net! For
example
when a function is just a wrapper around a library then you can use the
absolute
form of the docref parameter ("http://") to point to the library's
website.
>as a valid call from within an extension. Because this limits anytime
>this error occurs to the English manual description only, or any language
>which is defined really. There is no need for this, as you have provided
>another option which works much cleaner and better (through the ini
>options) in my opinion. While the PHP website may have a bug (or two) in
>it, it's no reason to force end users to be reading languages that they
>don't know or prefer.
>
>I have nothing wrong with:
>
>php_error_docref("function.fopen" TSRMLS_CC, E_WARNING, "Spongebob Square
>Pants lives in a pineapple under the sea");
>
>To me that should be the recommended method, as it will allow the php.ini
>values for language to override everything nicely, and everyone can see
>the PHP manual in their desired language. The error of course is still in
>English but thats another matter.
NULL or "#" is best here since it allows the phpdoc group to change
their
mind for naming the pages.
regards
marcus
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] $AUTHOR$ -> $Author$ ??
> Well, no file in the en tree is using $Author$ comments, but many > translation molude such as Italian and Japenese Translation as well as the > Chinese Molude is using the comment lines as following in every xml file: > > > > > > > However, you may find the second line above of the xml files in Italian or > Japenese molude are: > > > > It's not available for cvs to replace it correctly... So it's not in the howto, because it was not used widely when the howto's translation section was assemmbled. BTW what's the point in using that comment, can you please explain me? As you have a maintainer info in the translation comment and have a list of previous maintainers in the credits list, why you need to have an $Author? Which is even not the name of the person, who is the author, but who last modified the document isn't it? Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] php_error_docref
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
> >2) Can we please remove the "http://www.php.net/manual/en/blahblahblah";
> >style of use for this? It will tend to force users into one language or
> >another, and not make PHP as friendly/usable to other languages.
>
> NO! First you can simply set docref_root in your ini to point to your local
> copy of the manual in whatever language and Second it is a problem of
> the php website. It should automatically redirect from
> php.net/function.
> to php.net/manual//.php
I'm not sure I see the point still. What I'm proposing is not allowing:
php_error_docref("http://www.php.net/manual/en/function.fopen"; TSRMLS_CC,
E_WARNING, "Spongebob Square Pants rules");
as a valid call from within an extension. Because this limits anytime
this error occurs to the English manual description only, or any language
which is defined really. There is no need for this, as you have provided
another option which works much cleaner and better (through the ini
options) in my opinion. While the PHP website may have a bug (or two) in
it, it's no reason to force end users to be reading languages that they
don't know or prefer.
I have nothing wrong with:
php_error_docref("function.fopen" TSRMLS_CC, E_WARNING, "Spongebob Square
Pants lives in a pineapple under the sea");
To me that should be the recommended method, as it will allow the php.ini
values for language to override everything nicely, and everyone can see
the PHP manual in their desired language. The error of course is still in
English but thats another matter.
>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: [PHP-DEV] php_error_docref
At 16:37 13.08.2002, Dan Kalowsky wrote: >A few comments on this. > >1) is it possible to cut down on the number of php_error_docref functions >to just one? I really don't see a reason for this many different formats. There is no solution for reducing php_error_docref() to one function call but we could exchange all php_error() calls to php_error_docref(). Again see automatic exchange script: http://marcus-boerger.de/php/ext/docref.txt But who will do this? Me not. >2) Can we please remove the "http://www.php.net/manual/en/blahblahblah"; >style of use for this? It will tend to force users into one language or >another, and not make PHP as friendly/usable to other languages. NO! First you can simply set docref_root in your ini to point to your local copy of the manual in whatever language and Second it is a problem of the php website. It should automatically redirect from php.net/function. to php.net/manual//.php marcus -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/domxml/functions DomDocument-xinclude.xml
chregu Tue Aug 13 10:03:18 2002 EDT Added files: /phpdoc/en/reference/domxml/functions DomDocument-xinclude.xml Log: proto for DomDocument->xinclude() Index: phpdoc/en/reference/domxml/functions/DomDocument-xinclude.xml +++ phpdoc/en/reference/domxml/functions/DomDocument-xinclude.xml DomDocument->xinclude Substitutes XIncludes in a DomDocument Object. Description intDomDocument->xinclude &warn.experimental.func; &warn.undocumented.func; -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] $AUTHOR$ -> $Author$ ??
Well, no file in the en tree is using $Author$ comments, but many translation molude such as Italian and Japenese Translation as well as the Chinese Molude is using the comment lines as following in every xml file: However, you may find the second line above of the xml files in Italian or Japenese molude are: It's not available for cvs to replace it correctly... Greg "Gabor Hojtsy" <[EMAIL PROTECTED]> wrote in message 003c01c242ad$0cf9fb40$5a37a3d5@mia">news:003c01c242ad$0cf9fb40$5a37a3d5@mia... > > In zh translation molude team, we noticed that the Comment Line above > > the Revision Tracking Line in xml files should be '$Author$', but not > > '$AUTHOR'. When you pursue a CVS Commit, cvs will replace it with '$Author > : > > username$', in which username is the cvs username of the commiter of the > > file. > > > > Anyhow, the HOWTO documents doesn't mentioned it. Maybe it's not a > > official or recommended behavior? > > I may missed something... Show me a file in the en tree using $Author$ or > $AUTHOR$... > > Goba > > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18566 [Com]: comand line argument parsing with +
ID: 18566
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Windows
PHP Version: 4.2.1
New Comment:
with cgi 4.1.2 on win i get only strange results for a+b+c
php test.php a+b+c
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
Previous Comments:
[2002-08-13 08:09:11] [EMAIL PROTECTED]
Ups, I double checked my PHP version and it as 4.1.2 and not 4.2.1, so
I had more strange behaviours with the CGI version... Seems like some
things were corrected between 4.1.2 and 4.2.1...
[2002-08-13 08:01:45] [EMAIL PROTECTED]
with cgi-version(4.2.1, win2k):
test.php a b c
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
php test.php a+b+c
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
php test.php a=b=c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a=b=c"
}
php test.php a;b;c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a;b;c"
}
Only a+b+c seems to bahave "strange".
with cli-version(4.2.1,win2k):
php-cli test.php a b c
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
php-cli test.php a+b+c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a+b+c"
}
php-cli test.php a=b=c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a=b=c"
}
php-cli test.php a;b;c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a;b;c"
)
The same results for cgi and cli version in 4.2.2 on win.
Only a+b+c seems to be strange with the cgi.
Friedhelm
[2002-08-13 07:26:47] [EMAIL PROTECTED]
This was one of the reasons CLI was created in the first place - to get
rid of all CGI specific (mis)features.
This issue should probably be mentioned in the command line chapter.
[2002-08-13 07:21:20] [EMAIL PROTECTED]
I tested this with the CGI one, probably it's not a problem with the
CLI.
[2002-08-13 07:17:43] [EMAIL PROTECTED]
Is this still valid with the CLI? Or are you talking about the CGI
executable?
(Can't reproduce it with the CLI on Linux)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/18566
--
Edit this bug report at http://bugs.php.net/?id=18566&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18566 [Opn]: comand line argument parsing with +
ID: 18566
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Windows
PHP Version: 4.2.1
New Comment:
Ups, I double checked my PHP version and it as 4.1.2 and not 4.2.1, so
I had more strange behaviours with the CGI version... Seems like some
things were corrected between 4.1.2 and 4.2.1...
Previous Comments:
[2002-08-13 08:01:45] [EMAIL PROTECTED]
with cgi-version(4.2.1, win2k):
test.php a b c
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
php test.php a+b+c
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
php test.php a=b=c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a=b=c"
}
php test.php a;b;c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a;b;c"
}
Only a+b+c seems to bahave "strange".
with cli-version(4.2.1,win2k):
php-cli test.php a b c
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
php-cli test.php a+b+c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a+b+c"
}
php-cli test.php a=b=c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a=b=c"
}
php-cli test.php a;b;c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a;b;c"
)
The same results for cgi and cli version in 4.2.2 on win.
Only a+b+c seems to be strange with the cgi.
Friedhelm
[2002-08-13 07:26:47] [EMAIL PROTECTED]
This was one of the reasons CLI was created in the first place - to get
rid of all CGI specific (mis)features.
This issue should probably be mentioned in the command line chapter.
[2002-08-13 07:21:20] [EMAIL PROTECTED]
I tested this with the CGI one, probably it's not a problem with the
CLI.
[2002-08-13 07:17:43] [EMAIL PROTECTED]
Is this still valid with the CLI? Or are you talking about the CGI
executable?
(Can't reproduce it with the CLI on Linux)
[2002-07-25 11:41:21] [EMAIL PROTECTED]
The same effect is reproduceable with:
php test.php a=b=c
php test.php a;b;c
Goba
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/18566
--
Edit this bug report at http://bugs.php.net/?id=18566&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18566 [Com]: comand line argument parsing with +
ID: 18566
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Windows
PHP Version: 4.2.1
New Comment:
with cgi-version(4.2.1, win2k):
test.php a b c
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
php test.php a+b+c
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
php test.php a=b=c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a=b=c"
}
php test.php a;b;c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a;b;c"
}
Only a+b+c seems to bahave "strange".
with cli-version(4.2.1,win2k):
php-cli test.php a b c
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
php-cli test.php a+b+c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a+b+c"
}
php-cli test.php a=b=c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a=b=c"
}
php-cli test.php a;b;c
array(2) {
[0]=>
string(8) "test.php"
[1]=>
string(5) "a;b;c"
)
The same results for cgi and cli version in 4.2.2 on win.
Only a+b+c seems to be strange with the cgi.
Friedhelm
Previous Comments:
[2002-08-13 07:26:47] [EMAIL PROTECTED]
This was one of the reasons CLI was created in the first place - to get
rid of all CGI specific (mis)features.
This issue should probably be mentioned in the command line chapter.
[2002-08-13 07:21:20] [EMAIL PROTECTED]
I tested this with the CGI one, probably it's not a problem with the
CLI.
[2002-08-13 07:17:43] [EMAIL PROTECTED]
Is this still valid with the CLI? Or are you talking about the CGI
executable?
(Can't reproduce it with the CLI on Linux)
[2002-07-25 11:41:21] [EMAIL PROTECTED]
The same effect is reproduceable with:
php test.php a=b=c
php test.php a;b;c
Goba
[2002-07-25 11:35:56] [EMAIL PROTECTED]
I have tries the following script (test.php):
With:
php test.php a b c
and the results are:
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
What was new to me, is that
php test.php a+b+c
produces the same ;) So if this is intentional,
then it should be documented at least ;)
--
Edit this bug report at http://bugs.php.net/?id=18566&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18566 [Fbk->Opn]: comand line argument parsing with +
ID: 18566
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Documentation problem
Operating System: Windows
PHP Version: 4.2.1
New Comment:
This was one of the reasons CLI was created in the first place - to get
rid of all CGI specific (mis)features.
This issue should probably be mentioned in the command line chapter.
Previous Comments:
[2002-08-13 07:21:20] [EMAIL PROTECTED]
I tested this with the CGI one, probably it's not a problem with the
CLI.
[2002-08-13 07:17:43] [EMAIL PROTECTED]
Is this still valid with the CLI? Or are you talking about the CGI
executable?
(Can't reproduce it with the CLI on Linux)
[2002-07-25 11:41:21] [EMAIL PROTECTED]
The same effect is reproduceable with:
php test.php a=b=c
php test.php a;b;c
Goba
[2002-07-25 11:35:56] [EMAIL PROTECTED]
I have tries the following script (test.php):
With:
php test.php a b c
and the results are:
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
What was new to me, is that
php test.php a+b+c
produces the same ;) So if this is intentional,
then it should be documented at least ;)
--
Edit this bug report at http://bugs.php.net/?id=18566&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18566 [Fbk]: comand line argument parsing with +
ID: 18566
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Documentation problem
Operating System: Windows
PHP Version: 4.2.1
New Comment:
I tested this with the CGI one, probably it's not a problem with the
CLI.
Previous Comments:
[2002-08-13 07:17:43] [EMAIL PROTECTED]
Is this still valid with the CLI? Or are you talking about the CGI
executable?
(Can't reproduce it with the CLI on Linux)
[2002-07-25 11:41:21] [EMAIL PROTECTED]
The same effect is reproduceable with:
php test.php a=b=c
php test.php a;b;c
Goba
[2002-07-25 11:35:56] [EMAIL PROTECTED]
I have tries the following script (test.php):
With:
php test.php a b c
and the results are:
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
What was new to me, is that
php test.php a+b+c
produces the same ;) So if this is intentional,
then it should be documented at least ;)
--
Edit this bug report at http://bugs.php.net/?id=18566&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18566 [Opn->Fbk]: comand line argument parsing with +
ID: 18566
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Documentation problem
Operating System: Windows
PHP Version: 4.2.1
New Comment:
Is this still valid with the CLI? Or are you talking about the CGI
executable?
(Can't reproduce it with the CLI on Linux)
Previous Comments:
[2002-07-25 11:41:21] [EMAIL PROTECTED]
The same effect is reproduceable with:
php test.php a=b=c
php test.php a;b;c
Goba
[2002-07-25 11:35:56] [EMAIL PROTECTED]
I have tries the following script (test.php):
With:
php test.php a b c
and the results are:
array(4) {
[0]=>
string(8) "test.php"
[1]=>
string(1) "a"
[2]=>
string(1) "b"
[3]=>
string(1) "c"
}
What was new to me, is that
php test.php a+b+c
produces the same ;) So if this is intentional,
then it should be documented at least ;)
--
Edit this bug report at http://bugs.php.net/?id=18566&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/errorfunc/functions set-error-handler.xml
hholzgraTue Aug 13 05:56:32 2002 EDT
Modified files:
/phpdoc/en/reference/errorfunc/functionsset-error-handler.xml
Log:
sample code had a parse error
Index: phpdoc/en/reference/errorfunc/functions/set-error-handler.xml
diff -u phpdoc/en/reference/errorfunc/functions/set-error-handler.xml:1.6
phpdoc/en/reference/errorfunc/functions/set-error-handler.xml:1.7
--- phpdoc/en/reference/errorfunc/functions/set-error-handler.xml:1.6 Sat Jul 27
08:11:45 2002
+++ phpdoc/en/reference/errorfunc/functions/set-error-handler.xml Tue Aug 13
+05:56:31 2002
@@ -1,5 +1,5 @@
-
+
@@ -69,7 +69,7 @@
echo " Fatal error in line ".$errline." of file ".$errfile;
echo ", PHP ".PHP_VERSION." (".PHP_OS.")\n";
echo "Aborting...\n";
-exit 1;
+exit(1);
break;
case ERROR:
echo "ERROR [$errno] $errstr\n";
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] $AUTHOR$ -> $Author$ ??
> In zh translation molude team, we noticed that the Comment Line above > the Revision Tracking Line in xml files should be '$Author$', but not > '$AUTHOR'. When you pursue a CVS Commit, cvs will replace it with '$Author : > username$', in which username is the cvs username of the commiter of the > file. > > Anyhow, the HOWTO documents doesn't mentioned it. Maybe it's not a > official or recommended behavior? I may missed something... Show me a file in the en tree using $Author$ or $AUTHOR$... Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] developers manual and users manual
> May I suggest you just duplicate the entire current manual structures for > the new manual(s) and don't add any translation directories. That way when > someone decides they have to have the new manual in their native language > you don't have to work so hard to support it. They will eventually... Uh, it's not that easy. We have separate mailing lists for translations and separate CVS modules for every translation. Well, if we duplicate all these, we get a huge mess... If we push all users manual content one subdir down and make a new subdir for developers manual content (in all phpdoc modules), then we get a huge mess (there will be no CVS history for files, updates will get even harder). Actually I don't think so that someone can write a PHP extension if he even don't know English... PEAR, PHP-GTK, TSRM and other projects also copied the build system, so we have quite differently evolved build systems everywhere. Copying the build system does not help IMHO, but increases confusion, as different projects modify that initially same build system to their needs in different ways, so you cannot just jump in and work with another build system. For example the PEAR system uses XSL sheets exclusively, while we are just in the testing phase of converting to XSL sheets, and still use DSSSL ones, which require completely different conversion tools... Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
