Re: [PHP-DEV] Moderate PHP-DEV

[Philip Olson]

On Wed, 12 Mar 2003, Sascha Schumann wrote:

> > Yes, because getting a cvs account is just *s* hard.
> 
> The problem is that you easily lose valuable postings when
> you force people to go through some restrictive system.
> 
> I'm especially worried about inter-group communication.  E.g.
> where php-dev is involved in a discussion with another group
> of people.  If some developer list tries to protect itself
> from my input, I usually don't bother to jump through hoops.
> 
> This happened just recently with group@ and the ASF board
> where some messages got stuck in a filter.
> 
> > Currently, unless someone points me elsewhere I only read messages from
> > PHP core devs.
> 
> You must be kidding.  There are 20-30 emails on php-dev on
> normal days.  That hardly makes up 10% of my personal email
> traffic.  The volume is quite negligible from my POV.
> 
> Let's implement the renaming and Shane's two section thing
> first before we evaluate more draconic measures.

  I agree, it's worth looking into more subtle and less 
  controversial changes.  Change the name, clarify its 
  use (ex. move dev list signup..), and see what happens.

  Regards,
  Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Moderate PHP-DEV

[Philip Olson]

On Wed, 12 Mar 2003, Shane Caraveo wrote:

> Sascha Schumann wrote:
> >>if even that description doesn't work, then nothing would work, not even
> >>changing the name.
> > 
> > 
> > Well, it is obvious that some folks don't read that
> > description and simply move forward, because "php-dev" sounds
> > about right.  They are "PHP developers" and so a list called
> > "php-dev" makes absolute sense to them.
> > 
> > - Sascha
> > 
> 
> A couple thoughts
> 
> Aside from renaming the php-dev list, we should remove the 'PHP and Zend 
> Engine internals lists' from the regular mailing list page, put them in 
> a 'developers' section (name isn't important) that describes cvs access, 
> dev email lists, how to build (ie. win32 libraries), etc.  That way it 
> is completely removed from the regular stuff that normal php users will 
> gravitate towards.  It would help to clarify what is for the php 
> community at large, and what is for the community of developers that 
> work on php itself.
[snip]

  Related note: Separating the php manual into developer and user 
  versions is on the TODO.  There isn't a timeline.

  Regards,
  Philip



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-DOC] Re: function.main

[Philip Olson]

On Wed, 12 Feb 2003, Gabor Hojtsy wrote:

> >>>what is function.main? it keeps popping up on my requires and links to =
> >>>yoru site but nuthin' happens
> >>
> >>That is if I understand correctly a link in an error message. So either 
> >>PHP needs to hide that link in error messages, or the function.main 
> >>shortcut shuold point to somewhere on the homepage, explaining what is 
> >>function.main
> > 
> > This was fixed in CVS awhile ago (4.3.1) and now points to the
> > proper docs.  See: http://bugs.php.net/bug.php?id=21499
> 
> How was that fixed? Will there be any links with those errors for 
> function.main but for a different page, or no links? I think it would be 
> nice to make http://php.net/function.main show something (preferably the 
> same thing that this fixed error message points to), if applicable...

It was fixed in that it will link to documention for include()
or require() (depending on the error) instead of main().  So, 
it links to different yet more appropriate pages now.

Not sure if/what other errors cause a link to here but I
agree we may as well create a dummy page for main() with
some hopefully helpful information.  I just comitted main.xml
in /info/ so have a look, comments welcome.

Regards,
Philip




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-DOC] Re: function.main

[Philip Olson]

On Wed, 12 Feb 2003, Gabor Hojtsy wrote:

> > what is function.main? it keeps popping up on my requires and links to =
> > yoru site but nuthin' happens
> 
> That is if I understand correctly a link in an error message. So either 
> PHP needs to hide that link in error messages, or the function.main 
> shortcut shuold point to somewhere on the homepage, explaining what is 
> function.main

This was fixed in CVS awhile ago (4.3.1) and now points to the
proper docs.  See: http://bugs.php.net/bug.php?id=21499

Regards,
Philip



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Isis extension

[Philip Olson]

> I would like to know if can I have it on PECL. (There is a lot of people in
> latin-america who needs to use it, in europe too.)

Have a look here:
  http://pear.php.net/manual/en/guide-developers.php

It'll tell you how to get your extension into PECL. It
will be nice to add one more supported database to the
list :)

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] variables_order annoyance

[Philip Olson]

On Tue, 14 Jan 2003, Rasmus Lerdorf wrote:
> > Check out this bug report:
> > 
> >   http://bugs.php.net/16155
> 
> Ah thanks, that's where I remember the discussion from.  I do disagree 
> with one part:
> 
>(c) It shouldn't be possible to prevent $_GET, $_POST,
>$_COOKIE, and $_FILES from being populated.
> 
> Why in the world not?  I explicitly need to be able to prevent $_COOKIE
> from being populated and showing up in $_REQUEST here at Yahoo because we
> have access functions that we want to force people to go through to fetch
> cookie data.
> 
> I think we should just have a completely clean separation of variable 
> ordering priority and superglobal array population.  Before 
> register_globals it made sense to just have one setting for this as you 
> couldn't have one without the other, but today it doesn't make sense 
> anymore.

How about an ini setting for all autoglobals with all being
boolean except request_autoglobal which takes on 'gpc'.  This
will solve your problem but will introduce one possible problem 
(aside from even more directives to keep track of).  It's nice 
to document:

  "$_REQUEST will always contain a mix of..."

Instead of:

  "$_REQUEST may contain a mix of ... depending on your
   request_autoglobal directive."

Sure currently it depends on variables_order but few know the
true power of this directive and even fewer are tempted to
mess with it.  Having the contents being consistent is nice
but is it required?

One last thing.  Some people ask for the ability to hide certain ENV
and SERVER variables.  This is a related topic that might want to
be addressed at this time.  One thought for env:

  0   = Variable won't exist.
  1   = Entire variable will exist.
  "RUNLEVEL,PATH" = Partial variable exists except these.

BUT, this would mean getenv() would need to be brought into
the picture too so this topic will need a new related idea and
may want to be ignored for now :)  It would sorta be like
disable_variables vs disable_functions.

Regards,
Philip



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] variables_order annoyance

[Philip Olson]

On Mon, 13 Jan 2003, Rasmus Lerdorf wrote:

> Guys, I think this was brought up before, and I somehow had the impression
> that we fixed it, but we didn't.  Currently if variables_order does not
> contain a certain type then that type will not be populated in the $_FOO
> superglobal.  So, if you set variables_order = "GP" because you only want
> Get and Post data in your $_REQUEST array, perhaps, and you have
> register_globals off, then $_COOKIE, $_ENV, $_SERVER will not be 
> populated.  This is a pain in the ass!  The two concepts should be 
> separate.

Check out this bug report:

  http://bugs.php.net/16155

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CGI and CLI [packaging issues]

[Philip Olson]

> This goes with the PHP source approach:
> By default, "configure/make/make install" compiles the CGI interface,
> and then you have to "make install-cli" to get the CLI.
> 
> We just replace the "make install-cli" by "urpmi/apt-get php-cli".

Just FYI, 'make install-cli' is not the only way to
install the CLI there, 'make install' may put it 
there too.  For example:

  'make install' copies CLI to {prefix}/bin/php
  ./configure --with-apxs

  'make install' copies CGI to {prefix}/bin/php
  ./configure --enable-cli

  'make install' copies CGI to {prefix}/bin/php
  ./configure

This is because both --enable-cgi and --enable-cli
are defaults.  If one specifies a module SAPI, such
as apxs, then CLI is copied as 'php' because
--disable-cgi is implicitly called.  This manual
entry explains this further:

  http://www.php.net/features.commandline

This email is for informational purposes only, I do
not agree or disagree with your proposal as I wouldn't
touch this with a large stick but just wanted to clear 
up any possible misconceptions :)

Regards,
Philip



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ZEND_NUM_ARGS()

[Philip Olson]

On Sat, 4 Jan 2003, Sterling Hughes wrote:
> > Probably but it looks like that filetype(null); for example under windows
> > will return type directory...
> > 
> > So it looks an important bug too.
> > 
> 
> Its about as much of a bug as passing filetype(null) isn't a bug.

Okay, let's use filetype('somebogusname') as an example:

Linux:
 - Returns boolean false
 - E_WARNING about lstat failure...

Windows:
 - Returns string 'dir'
 - No E_WARNING

Is this how this is going to be forever?  Is this behavior
suppose to be documented?

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CVS Account Request: hitcho

[Philip Olson]

> > > Setup a common thread of examples across all PHP 
> > > documentation as 80% of all questions about PHP on 
> > > lists could be answered with common examples across 
> > > all functions in the documentation.

On Tue, 31 Dec 2002, Georg Richter wrote:
> On Tuesday 31 December 2002 22:39, Philip Olson wrote:
> 
> > 80% of all questions about PHP on the lists could be
> > answered if people read the manual in the first place.
> > Wait, make that 95% :)
> >
> 
> Philip, we need more examples (and also correct ones). Hitcho is absolutely 
> right here. Were also discussed this during the last doc meeting in march 
> 2002.

  Are more useful examples needed?  Yes.  Can the manual be
  improved?  Yes.  Will new better examples in the manual
  solve 80% of all problems?  No.  Do I want people like
  Hitcho to work on the manual?  Hell yeah!  Are my comments
  meant to be rude?  No.  Should people read the manual?  Yes.
  Do people who post to the lists currently read the manual?  
  Mostly No.  Should they?  Yes.  Should they also do searches
  with google/archives before asking?  Yes.

Regards,
Philip



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CVS Account Request: hitcho

[Philip Olson]

On 31 Dec 2002, Timothy Hitchens wrote:

> Docs:
> 
> Setup a common thread of examples across all PHP documentation 
> as 80% of all questions about PHP on lists could be answered 
> with common examples across all functions in the documentation.

80% of all questions about PHP on the lists could be
answered if people read the manual in the first place.
Wait, make that 95% :)

See also: google.com

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 4.3.0 released

[Philip Olson]

On Sat, 28 Dec 2002, Sander Steffann wrote:
> Hi All,
> 
> There is a weird line in here too:
> 
> >  * PHP Manual: Using PHP from the command line
> >http://www.php.net/manual/en/features.commandline.php
> 
> It's this one:
> By default when executing make, both the CGI and CLI are built and placed as
> sapi/cgi/php and sapi/cgi/php respectfully
> 
> The second path is wrong, and respectfully should be respectively.

These typos have been fixed in CVS, thank you for the report :)

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] CLI and CGI defaults

[Philip Olson]

> Andrei already decided, that --enable-cli should not change it's
> behavior for 4.3, allthough I think it's intuitive for --enable-cli to
> disable CGI if --enable-cgi was not given, I don't have a problem with
> it, as long as the NEWS entry is correct and Philip documents it
> correctly :)

I also feel an explicit --enable-cli should do that but 
regardless the current method has been documented.  The 
distinction can be seen in this unxmled excerpt:

 If a module SAPI is chosen during configure, such as apxs, 
 or the --disable-cgi option is used, the CLI is copied to
 {PREFIX}/bin/php during make install otherwise the CGI 
 is placed there. 

Because CLI is a SAPI so I guess only module (web servers) 
count.  Anyway please have a look at:

http://cvs.php.net/diff.php/phpdoc/en/features/commandline.xml?r1=1.12&r2=1.13

And make sure this is written correctly.  If so, information
from it will also live in install.commandline.  Btw, it sure
is weird writing examples when cgi and cli have the same 
name and get installed at the location.  I didn't change 
those much.  I also didn't add the history of what these 
files were called in 4.2.x as I'm not fully sure how it all 
worked back then *hint* *hint*.

Regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: ground rules

[Philip Olson]

Please have a look at bug #21116 as it mentions
php_printer.dll which is in php.ini but not in the
distro.  It does appear buildable as this dll can
be found here: http://kromann.info/php4.php I'm
not suggesting it be included as most likely it will
be removed from php.ini like the others.  This 
is in PECL now but that fact was never mentioned in 
NEWS.

Also, what is the official way windows users are 
suppose to get PECL dlls?  Build them themselves?

Regards,
Philip Olson


On Sat, 21 Dec 2002, Edin Kadribasic wrote:

> I have changed bundled php.ini-dist and php.ini-recommended to reflect these
> changes. Thanks for compilinng the list.
> 
> Edin
> 
> - Original Message -
> From: "Christoph Grottolo" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, December 21, 2002 10:40 PM
> Subject: [PHP-DEV] Re: ground rules
> 
> 
> > Hi
> >
> > Andrei Zmievski wrote:
> > > Everyone,
> > >
> > > I have just released 4.3.0RC4. Despite the quote in my signature, I am
> > > determined to keep this one the very last final RC of the interminable
> > > 4.3.0 development cycle. Towards that end, I will closely monitor the
> > > CVS commits and revert any that do not satisfactorily explain what
> > > critical or showstopper bug they are fixing.
> >
> > There are inconsistencies in php.ini on windows:
> >
> > The following extensions are listed in the [extensions] part of php.ini,
> but
> > are not dlivered with the distribution:
> > - ctype (now built in)
> > - cybercash (?)
> > - dotnet (build failure since months)
> > - ingres (build failure since months)
> > - tokenizer (now built in)
> >
> > The following extensions are part of the distribution but not listed in
> > php.ini
> > - gd2
> > - mime_magic
> > - msql
> > - xmlrpc
> > - zip
> >
> > Maybe you can correct this before 4.3.0. At least the missing GD2 is bad.
> >
> > Christoph
> >
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RC4: ground rules

[Philip Olson]

Attatched is a patch that essentially goes back
to 4.2.3 behavior except the external auth will not
be available with PHP in safe mode.  REMOTE_USER
exists regardless.  

It seems some people also wanted an ini option, I don't 
know how to do that! :)

References for this patch:
 http://bugs.php.net/20441
 http://cvs.php.net/diff.php/php4/sapi/apache/mod_php4.c?r1=1.132&r2=1.133

On a related note, I'm curious why PHP_AUTH_TYPE does
not exist, only the variable AUTH_TYPE does (for me).  
PHP_AUTH_TYPE has been documented forever, not sure if
it used to exist but various parts of PHP4 source make
it seem like it should.

Regards,
Philip Olson

p.s. Thanks to Wez and Steph for teaching me not to fear 
the source.


On Fri, 20 Dec 2002, Andrei Zmievski wrote:

> Everyone,
> 
> I have just released 4.3.0RC4. Despite the quote in my signature, I am
> determined to keep this one the very last final RC of the interminable
> 4.3.0 development cycle. Towards that end, I will closely monitor the
> CVS commits and revert any that do not satisfactorily explain what
> critical or showstopper bug they are fixing. I am aware that
> PHP_AUTH_USER issue raises certain concerns, but no one apparently could
> make a patch. If, however, one appears very soon, I may consider it a
> special one and apply it for 4.3.0.
> 
> -Andrei   http://www.gravitonic.com/
> 
> "The time from now until the completion
>  of the project tends to become constant." -- Douglas Hartree
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



Index: mod_php4.c
===
RCS file: /repository/php4/sapi/apache/mod_php4.c,v
retrieving revision 1.148
diff -u -r1.148 mod_php4.c
--- mod_php4.c  1 Dec 2002 03:28:21 -   1.148
+++ mod_php4.c  21 Dec 2002 05:18:12 -
@@ -448,7 +448,7 @@
authorization = table_get(r->headers_in, "Authorization");
}
if (authorization
-   && !auth_type(r)
+   && (!PG(safe_mode) || (PG(safe_mode) && !auth_type(r)))
&& !strcasecmp(getword(r->pool, &authorization, ' '), "Basic")) {
tmp = uudecode(r->pool, authorization);
SG(request_info).auth_user = getword_nulls_nc(r->pool, &tmp, ':');

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RC4: ground rules

[Philip Olson]

I'll have a patch in about one hour! :)

Regards,
Philip


On Fri, 20 Dec 2002, Andrei Zmievski wrote:

> Everyone,
> 
> I have just released 4.3.0RC4. Despite the quote in my signature, I am
> determined to keep this one the very last final RC of the interminable
> 4.3.0 development cycle. Towards that end, I will closely monitor the
> CVS commits and revert any that do not satisfactorily explain what
> critical or showstopper bug they are fixing. I am aware that
> PHP_AUTH_USER issue raises certain concerns, but no one apparently could
> make a patch. If, however, one appears very soon, I may consider it a
> special one and apply it for 4.3.0.
> 
> -Andrei   http://www.gravitonic.com/
> 
> "The time from now until the completion
>  of the project tends to become constant." -- Douglas Hartree
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CGI and CLI

[Philip Olson]

On Wed, 18 Dec 2002, Dan Kalowsky wrote:
> Cutting down on the list of receipients here...
> 
> Philip please do not put this paragraph into the documentation.  If 
> there is any sure fire way to ensure that the latest version of PHP 
> WON'T be installed on a system... it's to encourage end users to 
> contact their system administrator.

  Just FYI, I never intended to put that anywhere, it was more
  of a point to show how bad this can be.  A support nightmare
  is to encourage sysadmins to name the binaries whatever they
  feel like, with no set standard.  This sounds like PHP 4.3.0

  I have no solution except that whatever decision is made can
  be implemented in 4.3.0.  PHP 4.3.0 can wait an additional 
  month or three.  I see no reason why 4.3.0 should be pushed
  out the door just so 4.3.1 can implement this MAJOR change.

  It sounds like the two will be combined again, if so, make
  it so in PHP 4.3.0 please.  Same goes for if it's decided
  to keep the two separate.  Let the new RC series begin! :)

  Regards,
  Philip Olson


[snip]


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CGI and CLI

[Philip Olson]

So every tutorial and documentation on this would have to
say this right?

  "Ask your sysadmin what the CGI and CLI versions of your
   PHP are called, they could be anything as there is no
   standard.  For the purpose of this (tutorial|documentation), 
   we'll call CLI php-cli and CGI php-cgi."

Same goes for all cgi scripts, they'll work some places but
not others...  And various RPM's would have different naming
schemes depending on the maintainers preference.

Regards,
Philip


On Wed, 18 Dec 2002, Andrei Zmievski wrote:

> On Wed, 18 Dec 2002, Andi Gutmans wrote:
> > I doubt this will happen fast enough. We should just release the way we 
> > released 4.2.x, which as far as I know was php for CGI and php-cli for CLI 
> > or am I a bit behind things? :)
> 
> Derick and I hashed it out on IRC and we have a proposal:
> 
> We should keep 4.2.x behavior with some modifications. CLI and CGI
> should always be built unless disabled, and the executables should go
> into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install'
> target should be modified to detect whether the user is trying to
> install either one of these SAPIs, output a warning message regarding
> the potential naming problem, and stop. Let the user install CLI and CGI
> manually, basically.
> 
> I really hope we can come to an agreement on this.
> 
> -Andrei   http://www.gravitonic.com/
> * Quantum Mechanics: The Dreams of Which Stuff is Made. *
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Constants inside strings, sometimes

[Philip Olson]

Hello,

I stumbled upon this feature today and am wondering 
why it exists:

 'apple',
 'b' => 'banana',
 'c' => 'cranberry');

echo "a $arr[a] \n"; // apple
echo "b {$arr[a]} \n";   // banana (???)
echo "c {$arr['a']} \n"; // apple

echo "d $arr[b] \n"; // banana
echo "e {$arr[b]} \n";   // banana and E_NOTICE for
 // undefined constant

echo "f {a} \n"; // {a}

echo $arr[a];// banana (expected)
echo $arr['a'];  // apple
?>

In otherwords, constants are looked for inside 
strings under the following conditions:

a) It's an array key
b) {braces} are around the array

This seems like inconsistent behavior as that's
the only time they are looked for.  This makes 
sense outside of strings but inside of them only
if braces are used and with arrays?  Please 
explain.  It seems to me that if someone wants to
use constants with array keys, don't put them in 
strings.

Regards,
Philip Olson



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Location of getopt function

[Philip Olson]

One way to find function information is
through the php function reference:

  http://zend.com/phpfunc/function.getopt.php

Provides information on when it's available,
where it's defined, if it's documented, etc.

Regards,
Philip

On Mon, 16 Dec 2002, l0t3k wrote:

> Markus,
>   thanks for the link, but i was looking for the implementation of the PHP
> function as documented here
> http://www.php.net/manual/en/function.getopt.php
> 
> i searched for PHP_FUNCTION(getopt) but got no hits...
> 
> l0t3k
> 
> "Markus Fischer" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > On Sun, Dec 15, 2002 at 03:21:04PM -0500, l0t3k wrote :
> > > i've checked LXR, but i cant locate the implementation of getopt in CVS.
> im
> > > trying to provide a Windows implementation.
> >
> > HTH: http://lxr.php.net/find?string=getopt
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Philip Olson]

On Sun, 8 Dec 2002, Marcus [iso-8859-1] Börger wrote:

> At 17:55 08.12.2002, Philip Olson wrote:
> 
> >Wait, so there used to be a php-cli.exe ?  Add
> >that to the history request question :)
> >
> >And so a user tries to install via some install
> >tutorial on foo.com, what problems/errors will
> >they see when accessing via the browser?
> 
> There was no spoon :-) ok start again:

Not sure what this means.

> There was no cli and only cgi binary called php.exe.
> Then we decided to have a command line executable (abbrevation CLI).
> And the we decided to use 'php.exe' for the new CLI and to avoid confusion
> we chose to rename the CGI binary from 'php.exe'. So now there will be
> some books and other papers and online docs out there which state that
> php.exe has to be installedIn other words there will be users who install
> CLI as CGI what will lead into errors.

Please provide version numbers so it can be documented.  Like,
WHEN the changes happened.

Thanks,
Philip



--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Philip Olson]

Wait, so there used to be a php-cli.exe ?  Add
that to the history request question :)

And so a user tries to install via some install
tutorial on foo.com, what problems/errors will
they see when accessing via the browser?

Philip


On Sun, 8 Dec 2002, John Coggeshall wrote:

> 
> I believe the issue here is that PHP won't display the proper HTTP
> headers in the CLI version:
> 
> C:\> Php.exe test.php
> 
> X-Powered-By: PHP/4.2.2
> Content-type: text/html
> 
> Testing 1 2 3
> C:\>
> C:\> Php-cli.exe test.php
> Testing 1 2 3
> C:\>
> 
> >-Original Message-
> >From: Philip Olson [mailto:[EMAIL PROTECTED]] 
> >Sent: Sunday, December 08, 2002 11:07 AM
> >To: Alexander Wagner
> >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
> >'Christoph Grottolo'; [EMAIL PROTECTED]
> >Subject: Re: [PHP-DEV] php.exe - php-cgi.exe
> >
> >
> >
> >Can someone provide a history of this and the problems
> >one will see when trying to run php.exe as a cgi (i.e.
> >follows one of the many install texts out there).
> >
> >This is _sorta_ documented but not really, only the
> >apache2 docs make any mention of it thus far.
> >
> >Regards,
> >Philip
> >
> >
> >On Sun, 8 Dec 2002, Alexander Wagner wrote:
> >
> >> On Sunday 08 December 2002 01:02, John Coggeshall wrote:
> >> > I think a big ole' message at the end of ./configure will 
> >> > drastically reduce the number of problems.
> >> 
> >> With php.exe? *g*
> >> 
> >> > Also, perhaps a check could be put in the
> >> > CLI version of PHP that would throw an error message if it 
> >is being 
> >> > used as a CGI...
> >> 
> >> A _meaningful_ error-message in the right place would be the right 
> >> thing (tm).
> >> Too many people don't read release-notes.
> >> 
> >> regards
> >> Wagner
> >> 
> >> --
> >> codito ergo sum
> >> 
> >> --
> >> PHP Development Mailing List <http://www.php.net/>
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >> 
> >
> >
> >
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php.exe - php-cgi.exe

[Philip Olson]

Can someone provide a history of this and the problems
one will see when trying to run php.exe as a cgi (i.e.
follows one of the many install texts out there).

This is _sorta_ documented but not really, only the
apache2 docs make any mention of it thus far.

Regards,
Philip


On Sun, 8 Dec 2002, Alexander Wagner wrote:

> On Sunday 08 December 2002 01:02, John Coggeshall wrote:
> > I think a big ole' message at the end of ./configure will drastically
> > reduce the number of problems.
> 
> With php.exe? *g*
> 
> > Also, perhaps a check could be put in the
> > CLI version of PHP that would throw an error message if it is being used
> > as a CGI...
> 
> A _meaningful_ error-message in the right place would be the right thing (tm). 
> Too many people don't read release-notes.
> 
> regards
> Wagner
> 
> -- 
> codito ergo sum
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Modules/Extensions not in 4.3

[Philip Olson]

> On Fri, 29 Nov 2002, Wez Furlong wrote:
> IMO, the manual should include all of the "maintstream" PHP extensions.
> The reasoning is that if someone downloads the PHP manual, they expect
> to get the PHP manual and not have to hunt around for docs on extensions
> X, Y, Z.

So "mainstream" is defined as which are bundled with the
PHP4 source, whether it's in PECL or not?  Does anyone
know or have a list of what will go where and when? Is
the install, configure, and use process different for
PECL extensions?  Why are any PECL extensions bundled in
PHP4 source?  That seems to defeat the purpose.

Currently the php and pear docs are like separate entities,
perhaps we should tie them closer together.  Like,
download-docs.php can include versions with the pear manual.
And php.net/{pearextension} can either redirect to or
load appropriate manual/info pages.  Anyway, point is
they can be better and closer friends.

> Remember that one of our goals is to move most of ext/* into PECL, but
> still bundle these pickled extensions in our official release packages,
> so the idea that PECL should be documented under PEAR is not such a good
> one.

I'm not familiar with this topic.  Currently PECL is documented
under PEAR, and since it's part of PEAR it makes sense.  It's
hard enough to decide which extensions go into PECL let alone
which PECL are documented in what manual.  I am curious what is
meant by "most", that sounds a little scary and makes having
all extensions in one manual more attractive.  Is there an
option to only download needed pecl at compile time, kinda
like how 'pear install foo' is done now?  Or an option to
download each separate, or all of them at once?  I don't see
why any PECL would be bundled.  But anyway, back to the docs.

Some disadvantages of having the docs separate:

 * phpdoc has a ton more translators.
 * more people have phpdoc karma and feel comfortable
   touching phpdoc source
 * downloading two manuals and/or viewing two websites
 * "most" living in pecl, yet many bundled in php4

With the main advantage being it would be in its proper home.

> Again, IMO, the madness of having no less than 3 different docu systems
> (phpdoc, peardoc and peardoc2) makes very little sense; why not just use
> "one system (tm)" for docs? (let's save some developer brain power for
> more useful things).

The peardoc/peardoc2 issue is temporary and confusing but will
be remedied at some point, not sure when.  In fact, I personally
don't document pear because of it.  The matter of a completely 
separate PECL manual I also disagree with.  Although who knows,
maybe if the build processes were more closely done together it 
wouldn't be so bad.

> So, what I'd like to see (and this seems reasonable, IMO) is:
> 
> o One doc download for the PHP core + bundled extensions (which may
> reside in PECL).
> o One doc download for the PEAR classes + non-bundled PECL extensions
> o One doc download for extension developers (the streams and zend API
> stuff needs a proper home).
> o One doc system to rule them all (but keep it modular of course).

I agree with this except have reservations about some PECL
going in PEAR manual while others in the main manual.  I
*strongly* agree with a uniform system but AFAICT it won't
exactly be the case with current plans (phpdocumentor).

Regarding the separate developers manual, the main reason it
hasn't already been done (aside from time constraints) is there 
is question on whether it should be translated or not.  I vote no 
it shouldn't as that'd mean outdated developer docs as the zendapi 
stuff seems to change a lot and translations are slow and
sometimes are just one-time operations.  In fact, aren't the current 
en zendapi docs already outdated?  I don't know this topic.  On a 
related note, those PHP4/README.* docs would  fit nicely in this 
dev manual.

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Modules/Extensions not in 4.3

[Philip Olson]

> >> The peardoc format will be phased out for peardoc2 which
> >> uses several files, that is one per function, one for constants, 
> >> etc.
> >>
> >> It makes sense to document PECL in the pear manual since PECL is 
> >> in pear.
> >
> > Well, actually this what I wanted to hear :) I also think that moving
> > PECL module's manuals to PECL is the way to go. Those extensions are
> > mostly rarely used... We can make up a list in the manual about moved
> > extensions and some text about why this happened / happens...
>
> IMO, a lot of extensions that are currently documented in the PHP 
> manual could be moved to PECL and PEAR doc. This would make the 
> PHP manual lighter to download, display, handle. The PHP manual 
> could keep documentation about the core extensions (still to be
> defined).

This isn't really the question as we (the doc teams) don't make
these (php4/ext->pecl) decisions.  I don't think anyone feels 
the documentation of PECL modules belong in the php manual or 
vice versa but the question is how and when to deal with the 
moved extensions.  When the php-dev team moves an extension we:

  (a) Move the docs (phpdoc->peardoc)

  Verify the docs are online in the pear manual before removed
  from the php manual. (which means the peardoc vs peardoc2
  craziness must also be dealt with)

  (b) Make sure php.net/{extensionname} still does something
  useful.

  Whether filler pages or 404 handles this is in question.
  And whether or not individual functions are kept track
  of is another.  Also, this may just refer to (c).

  (c) Make a note in an up-and-coming phpdoc appendix page on
  moved and removed extensions which may look like:

  =
  | Extension | Change | Reason   | Moved in  |
  =
   aspell   removed  pspell..   4.3.0
   cybercashremoved  ...4.3.0
   cybermut moved..  ...4.3.0
  -

  (d) ???

Ideally the php-dev team can provide a timeline for (some) future
moves and/or discuss each extension in detail and make a decision.  
Maybe all moves have been completed?.  For now, we rely on NEWS 
entries.

Most of the above applies to removed extensions too except they
won't go into peardoc but rather remain in phpdoc for an
undisclosed (a long) amount of time.  A few were removed in 4.3.0, 
see NEWS and CVS entries for details.  Removed/deprecated 
extensions have been dealt with in a couple different ways:

  (1) icap   : php.net/icap simply redirects to php.net/mcal
   icap docs are not generated.
  (2) aspell : All deprecated functions have been listed for
   quite some time.  It also mentions "use pspell"
  (3) Redirect to (c) above.

I prefer the second because of historical reasons and the 
fact that users may still be using the old functions.  For
how long will these docs remain?  Should they ever go in the 
appendix instead?  Will this confuse users?  These are good 
questions :)  Also, what is done may depend on the individual 
extensions themselves although consistancy has its merits.

Regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Memory Error

[Philip Olson]

I started a faq on this but anyway one can
use K (kilobytes) or M (megabytes) for these
type of directives.  A plain integer == Bytes.

Regards,
Philip

On Wed, 27 Nov 2002, John Coggeshall wrote:

> >67108860 bytes = 64 mb
> 
> 64M will also work, I believe.
> 
> John
> 
> 
> 
> >
> >
> >"Jonathan Williams" <[EMAIL PROTECTED]> wrote in message 
> >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> >> Could someone 
> >please help.  Running Linux 7.3 RH with 512 MB Ram with 
> >> Apache and PHP 4.  I receive the following error and was 
> >wondering if 
> >> anyone had any suggestions.  The error: Fatal error: Allowed memory 
> >> size of 8388608 bytes exhausted (tried to allocate 35 bytes) in 
> >> /var/www/html/vc/test_fort/bootstrap.php on line 267.  Is there a 
> >> server setting eliminating the ability to allocate more memory.  Any 
> >> suggestions would be helpful.  You can reply to [EMAIL PROTECTED] 
> >> as well.
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> --
> >> PHP Development Mailing List 
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Redirect patch URL

[Philip Olson]

Regarding this proposal, what happens if the url being 
redirected to has an error?  Or if it's down for some
reason, how can I still see my errors without bugging 
the sysadmin?  Also, will CLI and CGI be affected too?

Regards,
Philip

On Tue, 26 Nov 2002, John Coggeshall wrote:

> 
> http://coogle.homeip.net:81/php/patches/error_redirect.txt
> 
> John
> 
> >-Original Message-
> >From: Derick Rethans [mailto:[EMAIL PROTECTED]] 
> >Sent: Tuesday, November 26, 2002 4:22 PM
> >To: John Coggeshall
> >Cc: 'PHP Developers Mailing List'
> >Subject: Re: [PHP-DEV] Redirect patch URL
> >
> >
> >On Tue, 26 Nov 2002, John Coggeshall wrote:
> >
> >> 
> >> http://coogle.homeip.net:81/php/patches/error_redirect.html
> >> 
> >> Please check out this URL and let me know what you guys think of the 
> >> second version of this patch. It basically is pretty solid at this 
> >> point.
> >
> >Your diff is in the wrong order, the whitespace is totally 
> >screwed, and 
> >putting it in HTML makes it not readable at all. Can you 
> >please put up a 
> >patch in a plain text file and with the correct +/- things?
> >
> >Derick
> >
> >-- 
> >
> >---
> >--
> > Derick Rethans 
> >http://derickrethans.nl/ 
> > PHP Magazine - PHP Magazine for 
> >Professionals   http://php-mag.net/
> >---
> >--
> >
> >
> >
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Concrete suggestion re: i18n messages

[Philip Olson]

> > No, it does not to me. It means that translators need to have access to
> > the php4/ cvs module, which is something I'm very against.
> 
> Agreed..  The default messages stay in the source code and
> are easily reachable for the developer.
> 
> (That is something I very much dislike about the current
> phpdoc organization.  Every time I want to change something
> in the main English documentation, I need to hunt around for
> remote, well-hidden xml files.  The docs were more
> up-to-date, if these files were easier to access.)

Please explain this a little more with a few specific
examples.  And please write the phpdoc list with these
concerns.  Maybe the structure can be further explained
in the doc HOWTO.  Sometimes I find going to the URL of
the manual page helps figure out the location:

  www.php.net/manual/en/language.variables.predefined.php
  en/language/variables.xml

  www.php.net/manual/en/tokens.php
  en/appendices/tokens.xml (note it's in appendix in manual)

Finding functions and extension information is easy since the 
big change about seven months ago, for example:

  www.php.net/manual/en/function.{functionname}.xml
  en/reference/{extensionname}/functions/{functionname}.xml

  www.php.net/manual/en/ref.{extensionname}.php
  en/reference/{extensionname}/reference.xml

Adding functions is simple, just go into the appropriate
extensions function directory and add the xml file.  On
a related note, the change/split that happened awhile back:

  Old:  en/functions/{extension}.xml
  New:  en/reference/{extension}/functions/{function}.xml
/ini.xml
/reference.xml
/constants.xml
/functions.xml (autogenerated)

Don't edit functions.xml as it's an autogenerated list. Also
note that the Old files are still in CVS for historical and
archival purposes (the changelogs).

It does take a little getting used to but let's discuss it
a little so php-dev people will feel more comfortable.  It
now seems intuitive to me although it's not perfect and
changes are still in progress.  For example finding some
of the configuration directives can be difficult...

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Philip Olson]

On Tue, 26 Nov 2002, Stanislav Malyshev wrote:

> PO>> Just to defend phpdoc a bit, this statistic is based on
> PO>> a php manual generated on April 25, 2002, which is when
> PO>> zend.com/manual/ was last updated.  Also, missing functions
> 
> That's not exactly true. The phpfunc is updated much more frequently than 
> the manual (since it takes _a real lot_ of time to build the full 
> manual...) - usually, daily. Also, as far as I understand, the numbers are 
> taken from manual/PHP sources, not from generated manual. 
> So if something is not correct, it's because I messed something up or 
> something changed in the manual and phpfunc script no longer catch it - 
> but not because it's not updated. Can you point to some function that is 
> defined but listed as not defined? Did the manual structure change 
> substantially? 

Yes, phpfunc updates daily and that is good (although it continues 
to say last updated sept. 22).  There are documented functions 
listed as not documented but your last comment seems to decipher 
why.  Sorry to assume where those statistics are based although 
this looks related as April 25 is close to April 17, which
is around when the big change happened.

The manual structure did substantially change at around April
17, 2002.  Now the functions are in their own xml files, and 
they all live in the reference/ directory.  The old xml files 
still exist but aren't updated anymore.  So:

  Old:  en/functions/{extension}.xml
  New:  en/reference/{extension}/functions/{function}.xml

It sounds like this is where the problem lives.  As a reference, 
glob() was initially documented about six months ago and sha1() 
about six days.

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Philip Olson]

[snip]
> Really? Let's see on average each function generates @ least one warning 
> message, so we have @least as many warnings as we have functions. Warning 
> messages get constantly re-arranged, by having a separate database for them 
> making changes to warning messages will become more complex then writing the 
> actual code. So, people will in many cases cut corners and just RETURN_FALSE; 
> without giving a detailed explanation. Most developers like to write code, 
> not modify XML files & and write essays for proof look @ 
> http://www.zend.com/phpfunc/statistics.php, according to that page ~14% of 
> all functions in PHP are not documented in the English language.

Just to defend phpdoc a bit, this statistic is based on
a php manual generated on April 25, 2002, which is when
zend.com/manual/ was last updated.  Also, missing functions
are almost all from experimental and/or cvs only functions.  
Sure your point is still valid (php-dev would rather code than 
document) but the numbers are a little misleading... and that's 
why such a great phpdoc team exists :)

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PATCH] Redirect on Error

[Philip Olson]

On the documentation side of things, each translation
could include a page tentively called:

  "English words you want to know"

It could be as simple as a three column table, such as:

| English   | German | Explanation |

| Constant  | Konstant   | ... |
| Undefined | Unbestimmt | E_NOTICE... |
| Notice| Nachricht  | E_NOTICE... |

The explanation column could give the context of the
word although maybe that's overkill.  Also something
to consider is the currently existing tokens page:

  http://www.php.net/manual/en/tokens.php

Which lists T_SR, T_VARIABLE, etc. And it both
shows some example syntax as well as a link to
the appropriate [translated] manual page.

Also, it seems one should understand the word 'array'
before using functions named array_keys() or array().
And know the word NOTICE because of E_NOTICE...

Regards,
Philip

p.s. please forgive my poor german.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] php4/win32/install.txt

[Philip Olson]

Hello all-

Here's a small patch that mentions apache2 for windows users.  
Related bugs on this issue can be seen here:

  * http://bugs.php.net/bug.php?id=16744
  * http://bugs.php.net/bug.php?id=18129

Bug #18129 virtually became a support thread for this
topic.

The following patch doesn't go into detail as I don't feel 
comfortable with the subject but it at least gives an idea 
on what to do.  Anyone feel free to go into more detail or
adjust the words below before commit :)



--- win32/install.txt   26 Sep 2002 19:49:34 -  1.16
+++ win32/install.txt   19 Nov 2002 07:27:53 -
@@ -48,6 +48,7 @@
   Personal Web Server 3 and 4 or newer
   Internet Information Server 3 and 4 or newer
   Apache 1.3.x
+  Apache 2.0.x  (experimental)
   OmniHTTPd 2.0b1 and up
   Oreilly Website Pro
   Xitami
@@ -201,6 +202,21 @@
 

  Installing PHP on Windows with Apache 1.3.x
+
+  
+  ATTENTION: Apache 2 Users
+
+At this time, support for Apache2 is experimental.  It's
+highly recommended you use PHP with Apache 1.3.x and not
+Apache2.  Documentation for installing Apache2 on windows 
+can be seen here:
+
+   http://www.php.net/manual/en/install.apache2.php
+
+With the basic difference being that when installing as a 
+module you'll use php4apache2.dll instead of php4apache.dll
+Both files are included within this release.
+  
+


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] karma++

[Philip Olson]

Hello-

I request karma for phpweb and php4/NEWS  

I will help close bugs related to these 
categories and help make improvements.

Regards,
Philip Olson

user: philip


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] $HTTP_RAW_POST_DATA

[Philip Olson]

On Mon, 11 Nov 2002, Hartmut Holzgraefe wrote:
> Philip Olson wrote:
> > When setting this on I assume it will always populate no matter
> > what enctype is used.  This isn't the case.  In the little tests
> > according to Brad, adding enctype="multipart/form-data" to a
> > post form will cause $HTTP_RAW_POST_DATA to not exist.  This is
> > even with aways_populate_raw_post_data = on.
> 
> unless i did something stupid while testing this is also the case
> at least for 4.2.x (due to the way multipart forms are handled now
> to preserve memory on file uploads) ...

I meant that in 4.2.3 it seems broke.  Regardless of
always_populate_raw_post_data setting, a POST form doesn't
always populate $HTTP_RAW_POST_DATA like it should*.

Related changelog entries:

 4.2.0
 - Fixed $HTTP_RAW_POST_DATA to be populated on a missing 
   content-type when always_populate_raw_post_data is on. 
   (Rasmus)

 4.1.0
 - Add config option (always_populate_raw_post_data) which 
   when enabled will always populate $HTTP_RAW_POST_DATA 
   regardless of the post mime type 
   (Rasmus)

So I'm not sure what to say.  In 4.2.3 it's very possible
to make $HTTP_RAW_POST_DATA not exist with this directive
on (assuming POST data exists of course).  Please advise
if this behavior has or will change.  Or explain why this
is the case.

Regards,
Philip

* Whether it should or not is in question.


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] $HTTP_RAW_POST_DATA

[Philip Olson]

On Sun, 10 Nov 2002, Rasmus Lerdorf wrote:
> Hrm..  Ok, actually Hartmut changed this recently.  See:
> 
> 
>http://cvs.php.net/diff.php/php4/main/php_content_types.c?login=2&r1=1.21&r2=1.22&ty=u
> 
> It works when you turn on always_populate_raw_post_data, right?

When setting this on I assume it will always populate no matter
what enctype is used.  This isn't the case.  In the little tests
according to Brad, adding enctype="multipart/form-data" to a
post form will cause $HTTP_RAW_POST_DATA to not exist.  This is
even with aways_populate_raw_post_data = on.

Until this is figured the documentation won't be updated and
imho this directive is considered broke.  I am unable to test
cvs php module at this time nor am I a HTTP expert.  I tested
on 4.2.3 and the above behavior exists.  Shouldn't always mean
always?  I'm unable to confidently decipher that diff.

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] $HTTP_RAW_POST_DATA

[Philip Olson]

This will be documented as soon as we figure out where
to document it.  Many months ago the predefined variables
section of the manual was redone and the vars are now 
separated autoglobals.

Should this be documented under $GLOBALS or should a
new section be created?  I'm thinking a new section
for "other" variables such as this.  If you can think
of other vars and/or have a better idea please speak up.  
Here's a diff:

RCS file: /repository/phpdoc/en/appendices/reserved.xml,v
retrieving revision 1.26
diff -u -r1.26 reserved.xml
--- en/appendices/reserved.xml  6 Nov 2002 22:36:55 -   1.26
+++ en/appendices/reserved.xml  10 Nov 2002 02:27:36 -
@@ -933,6 +933,28 @@
  option is turned on (it defaults to off).
 

+
+   
+Other predefined PHP variables
+
+ 
+  
+   
+$HTTP_RAW_POST_DATA
+
+ 
+  Contains the RAW POST data.  For this variable to exist, 
+  there must be a POST request and either the mime type of 
+  the POST data must be unrecoginized or the PHP directive
+  
+  always_populate_raw_post_data is set to 
+  on.
+ 
+
+   
+  
+ 
+
+
+



On Sat, 9 Nov 2002, Rasmus Lerdorf wrote:

> Yes, it has to be a POST request for there to be post data and
> $HTTP_RAW_POST_DATA is populated if the mime type of the data is
> unrecoginized or if always_populate_raw_post_data is on.
> 
> On Sat, 9 Nov 2002, Kjartan Mannes wrote:
> 
> > Wednesday, August 28, 2002, 3:15:13 PM, [EMAIL PROTECTED] wrote:
> > > is $HTTP_RAW_POST_DATA only filled if REQUEST_TYPE is set to POST?
> > > even if 'always_populate_raw_post_data = On'? does anyone have a short
> > > info on this? rasmus maybe?
> >
> > I to would like know when $HTTP_RAW_POST_DATA is supposed to be set. I
> > recently upgrade from 4.2.3 to 4.3.0-dev and one of my scripts stopped
> > working as $HTTP_RAW_POST_DATA wasn't set when data was POSTed. To fix
> > this I had to turn always_populate_raw_post_data on. Any documentation
> > on this variable should work?
> >
> > --
> > Kjartan <[EMAIL PROTECTED]> (http://natrak.net/)
> > :: "Scandisk is now checking your hard disk. You can start
> > praying."
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please help document headers_sent()

[Philip Olson]

On Wed, 6 Nov 2002, Ilia A. wrote:

> On November 6, 2002 07:10 pm, Philip Olson wrote:
> > I get a Segmentation fault with this script using
> > PHP CLI:
> >
> >  > headers_sent($file, $line);
> > ?>
> >   philip@rock:~$ php test.php
> >   Segmentation fault
> >
> > That's when no headers are sent before the call.  But if
> > headers are sent beforehand, it works:
> 
> The crash has been fixed in the CVS. PHP CLI cannot send any headers because 
> it is not ment for a webserver enviroment. While CGI, is mostly geared 
> towards web servers and by default will try to send headers.

Okay cool.  I just built from CVS and can confirm
it has been fixed :)  This time I used --enable-debug too ;)
I couldn't build from HEAD yesterday but it's okay today.

Regards,
Philip


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please help document headers_sent()

[Philip Olson]

I get a Segmentation fault with this script using
PHP CLI:


  philip@rock:~$ php test.php
  Segmentation fault

That's when no headers are sent before the call.  But if 
headers are sent beforehand, it works:


  philip@rock:~$ php test.php
  foo
  test.php : 2

With a fairly (a few weeks old) version of PHP CLI.
I am unable to do further tests at this time, in fact,
I am unable to build HEAD (it dies).  Only CLI seems
to be affected, CGI works either way.  Haven't
tested mod.

Regards,
Philip Olson

P.s. If no headers were sent, in CGI, $line gets
the value int 0.  $file is an empty string.




On Wed, 6 Nov 2002, Philip Olson wrote:

> 
> > On Wed, 6 Nov 2002, Wez Furlong wrote:
> > if (headers_sent($file, $line)) {
> >   echo "headers were sent by $file:$line";
> > }
> [snip]
> 
> Hello Wez-
> 
> Ahh, that makes sense.  I was a little off
> base on that one! :)  Will add an example now.
> 
> Regards,
> Philip
> 
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please help document headers_sent()

[Philip Olson]

> On Wed, 6 Nov 2002, Wez Furlong wrote:
> if (headers_sent($file, $line)) {
>   echo "headers were sent by $file:$line";
> }
[snip]

Hello Wez-

Ahh, that makes sense.  I was a little off
base on that one! :)  Will add an example now.

Regards,
Philip




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Please help document headers_sent()

[Philip Olson]

Hello-

headers_sent() has two new parameters as of PHP 
4.3.0, these are passed in by reference.  I see
no need to have to do:

  $file = 'file.php';
  $line = 4;

  headers_sent($file, $line);

When one could simply do this:

  headers_sent('file.php', 4);

But we can't, we get this error:

  Fatal error: Only variables can be passed by reference

This doesn't seem important, forcing one to use 
variables here seems odd, why?  Yes & is in the
proto but afaict it shouldn't be.

On a related note, I tried and failed to return
anything other then 1 while using these optional
parameters.  I can't even tell if it's reading
the file.  If someone could explain a little more
that would be very cool.

Regards,
Philip



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-DOC] Re: Manual page suggestions (was: dba_open...)

[Philip Olson]

> Some function return NULL some return FALSE and some return
> either FALSE or NULL in case of an error.

And some return -1, some iirc return 0.  I believe this
is because PHP is open source and developers provide
return values based on their personal preferences.  But I'm
not a php-dev guy so am not fully sure on the specifics
or the history associated with this phenomena.

Each function is documented on what it returns.  If it
isn't, we add such documentation.  Most functions return
false on failure, not all.  As long as 0 isn't expected,
using != to compare is often what people do.  People only
use strict !== when they are 100% sure what it'll return.

> Some function use NULL to tell there was a parser error and FALSE for
> other errors. If so one cannot do something like:
> if (xxx() !== false) ...
> or
> if (!is_null(xxx())) ...
> instead you would have to use
> if (($res = xxx() !== false) && !is_null($res)) ...

If that's how the function behaves and is documented then
so be it.  I too find it a little confusing having functions
return -1, 0, false or null but that's the way it is right
now.  Maybe this has been addressed?

> I posted the full thing already here. That also contains an analysis of
> some function documentations:
> http://marc.theaimsgroup.com/?l=php-dev&m=103376370906751&w=2

That looks interesting and until such a rapid change happens, or
a decision is made to use your doc method, we should continue to
document functions in a consistent manner which means not including
the failed return value in the proto.

Regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: #19848 [Ctl->Csd]: Wrong $_REQUEST values ($_FILESappearance is wacky)

[Philip Olson]

> > is import_request_variables() affected?

> as for import_request_variables, I haven't modified that, simply because
> i'm not sure whether it should be modified...  For now I'll leave it, if
> someone feels strongly about it either way, they can change it...

I think they should be the same, if $_REQUEST does not have
FILES, import_request_variables() shouldn't either.  I lack
the skills to implement this change but vote for it 
nonetheless ;)  Mainly for consistency sake.

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: #19848 [Ctl->Csd]: Wrong $_REQUEST values ($_FILES appearanceis wacky)

[Philip Olson]

This change will make it into 4.3.0 right?  Also, 
is import_request_variables() affected?

Regards,
Philip


On 28 Oct 2002 [EMAIL PROTECTED] wrote:

>  ID:   19848
>  Updated by:   [EMAIL PROTECTED]
>  Reported By:  [EMAIL PROTECTED]
> -Status:   Critical
> +Status:   Closed
>  Bug Type: HTTP related
>  Operating System: *any
>  PHP Version:  4.2.3,4,3.0-dev
>  Assigned To:  sterling
>  New Comment:
> 
> Fixed in CVS... $_FILES is no longer present in $_REQUEST...
> 
> 
> Previous Comments:
> 
> 
> [2002-10-24 18:42:14] [EMAIL PROTECTED]
> 
> This test form strips 3 characters from the posted variable:
> 
> 
> 
> 
> 
> 
> 2 dimensional array - this test form strips 8 characters from the
> posted variable:
> 
> 
> 
> 
> 
> 
> For every dimension added to the array, another 4 characters are
> scripted from the beginning of the posted variable.  Works on PHP
> version less than 4.2.2 and earlier.
> 
> 
> 
> [2002-10-20 22:17:12] [EMAIL PROTECTED]
> 
> The 'voting' on php-dev was in favour for removing the $_FILES from
> $_REQUEST..as it doesn't make much sense
> to have them there. Just FYI. :)
> 
> --Jani
> 
> 
> 
> 
> [2002-10-20 22:14:01] [EMAIL PROTECTED]
> 
> Sterling Hughes is working on this issue, according to posts to
> php-dev.
> 
> 
> 
> 
> [2002-10-16 06:29:23] [EMAIL PROTECTED]
> 
> Also got the same cases.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> print_r($_POST['server']);
> 
> it comes out:
> ---
> Array 
> ( 
> [0] => ASP 
> [1] => C# 
> [2] => FUSION 
> [3] => 
> [4] => 
> [5] => PHP 
> ) 
> 
> Apache/1.3.26, Win98
> 
> 
> 
> [2002-10-15 15:21:27] [EMAIL PROTECTED]
> 
> BTW, 17958 is "no feedback".
> Well, that's pretty untrue ...
> 
> 
> 
> 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/19848
> 
> -- 
> Edit this bug report at http://bugs.php.net/?id=19848&edit=1
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] --disable-cgi yet again

[Philip Olson]

Shouldn't this be --disable-cli ?

On Thu, 10 Oct 2002, Andrei Zmievski wrote:

> Can someone good with build system add --disable-cgi swtich, please?
> There is a patch in php-dev archives but it doesn't work against the
> current tree. I hate building cgi every time when I don't need it.
> 
> -Andrei   http://www.gravitonic.com/
> 
> "Music expresses that which can not be said
>  and on which it is impossible to be silent."
>  -Victor Hugo
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] variables_order too powerful

[Philip Olson]

Can someone look into this for 4.3.0?  I think 
this would go nicely there.

Regards,
Philip


On Tue, 16 Jul 2002, Philip Olson wrote:

> In this bug report:
> 
>   variables_order affects existence of php 
>   predefined variables
> * http://bugs.php.net/16155  
> 
> The following tentative plan was made by Zeev:
> 
> (a) Decouple variables_order from the $_* / $HTTP_*_VARS
> completely.
> (b) Make it possible to prevent $_ENV and $_SERVER from
> being populated.  Something like: 
>   server_autoglobal = on
>   env_autoglobal = off
> (c) It shouldn't be possible to prevent $_GET, $_POST,
> $_COOKIE, and $_FILES from being populated.
> 
> This is a pretty interesting change, the php-dev crew 
> may want to discuss it (and implement!).
> 
> Regards,
> Philip Olson
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] variables_order too powerful

[Philip Olson]

In this bug report:

  variables_order affects existence of php 
  predefined variables
* http://bugs.php.net/16155  

The following tentative plan was made by Zeev:

(a) Decouple variables_order from the $_* / $HTTP_*_VARS
completely.
(b) Make it possible to prevent $_ENV and $_SERVER from
being populated.  Something like: 
  server_autoglobal = on
  env_autoglobal = off
(c) It shouldn't be possible to prevent $_GET, $_POST,
$_COOKIE, and $_FILES from being populated.

This is a pretty interesting change, the php-dev crew 
may want to discuss it (and implement!).

Regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] passing variables need help

[Philip Olson]

Hello John-

Please consider the following two locations:

  http://www.php.net/support
  http://www.php.net/variables.external

Regards,
Philip Olson


On Mon, 15 Jul 2002, John Flanagan wrote:

> Lo,
> 
> I am a just starting with PHP and I am in the middle of building a site. What my 
>question is;
> 
> If I pass a variable to a page by www.mysite.com/index.php?page=support how do I 
>grab that variable and use it in the index.php.
> 
> I want to use the same index.php for the whole site and when I get the variable eg 
>support pass it in to a variable like "pages/{$page}.php";   to stop any directory 
>transversal attacks.
> 
> I would appreciate it if anyone could tell me how to get the variable from the URL.
> 
> 
> Cheers,
> 
> John F
> [EMAIL PROTECTED]
> 
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Bug #18214 Updated: Request: Warning on assignment in IFexpression.

[Philip Olson]

> What are some other potential "strict" mode watches?  Some people
> ask for an optional "strict" mode with various options, this could
> be a good start?  Imagine a strict mode directive where when on,
> various > options could be set at runtime, like
> assignment_inside_expression = true :)
> 
> You can better do this discussion on php-dev, as not a lot people 
> read the bug list.

Here are a few related feature requests (with summary):

  #14285 - Wants strict mode, similar to:
  'option explicit' in VBScript
  'use strict'  in Perl

  #14405 - Wants 'require strict argument' option, that 
   affects all PHP functions.  The name E_TYPE 
   is suggested.
  
  #18214 - Wants warning option for assignment inside of an 
   expression.  Possible runtime option of 
   assignment_inside_expression = true if in strict 
   mode.

How possible would it be to create an optional strict 
mode in PHP?  This might help "strict" programmers feel 
more comfortable.  error_reporting(E_ALL) is a start, 
using === vs == too.  Some functions, like in_array(), 
have strict options now as well.

Regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-DOC] cvs: phpdoc /en/reference/info/functionsini-set.xml

[Philip Olson]

How about we add another column to the ini_set() 
docs that explain these issues.  Like for 
register_globals say why it won't give you 
$id from GET, etc. But why you might want to 
set it at runtime.  

Basically, people assume "can be set at runtime" 
means the directive can be set at runtime, and 
most expect in the same way as setting in php.ini

Regards,
Philip Olson


On Mon, 8 Jul 2002, Philip Olson wrote:

> There are several inconsistencies similar to this 
> one.  main.c and similar just don't always "look right."
> 
> I never made an official bug report but check out this 
> php-dev post:
> 
>   PHP_INI USER|PERDIR|SYSTEM|ALL
>   http://marc.theaimsgroup.com/?l=php-dev&m=101198971703359
> 
> Currently this ini_set table is autogenerated from 
> source, but the source isn't always real world and 
> imho the ini_set() table should be as "friendly" 
> as possible (no more support questions! :)
> 
> Regards,
> Philip Olson.
> 
> 
> On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote:
> 
> > On Mon, 8 Jul 2002, Philip Olson wrote:
> > 
> > > philipMon Jul  8 02:31:59 2002 EDT
> > > 
> > >   Modified files:  
> > > /phpdoc/en/reference/info/functions   ini-set.xml 
> > >   Log:
> > >   register_globals can't really be set by USER with ini_set().
> > 
> > The documentation doesn't match the source now, which is:
> > 
> > STD_PHP_INI_BOOLEAN("register_globals", "0",PHP_INI_ALL,
> > 
> > So I guess we need to fix that too?
> > 
> > Derick
> > 
> > >   
> > >   
> > > Index: phpdoc/en/reference/info/functions/ini-set.xml
> > > diff -u phpdoc/en/reference/info/functions/ini-set.xml:1.12 
>phpdoc/en/reference/info/functions/ini-set.xml:1.13
> > > --- phpdoc/en/reference/info/functions/ini-set.xml:1.12   Tue Jun 18 08:06:10 
>2002
> > > +++ phpdoc/en/reference/info/functions/ini-set.xmlMon Jul  8 02:31:58 
>2002
> > > @@ -1,5 +1,5 @@
> > >  
> > > -
> > > +
> > >  
> > >
> > > 
> > > @@ -975,7 +975,7 @@
> > >
> > > register_globals
> > > "0"
> > > -   PHP_INI_ALL
> > > +   PHP_INI_PERDIR|PHP_INI_SYSTEM
> > >
> > >
> > > safe_mode
> > > 
> > > 
> > > 
> > > -- 
> > > PHP Documentation Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > 
> > 
> > ---
> >  Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
> >  Frequent ranting: http://www.derickrethans.nl/
> > ---
> >  PHP: Scripting the Web - [EMAIL PROTECTED]
> > All your branches are belong to me!
> > SRM: Script Running Machine - www.vl-srm.net
> > ---
> > 
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 





-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-DOC] cvs: phpdoc /en/reference/info/functions ini-set.xml

[Philip Olson]

There are several inconsistencies similar to this 
one.  main.c and similar just don't always "look right."

I never made an official bug report but check out this 
php-dev post:

  PHP_INI USER|PERDIR|SYSTEM|ALL
  http://marc.theaimsgroup.com/?l=php-dev&m=101198971703359

Currently this ini_set table is autogenerated from 
source, but the source isn't always real world and 
imho the ini_set() table should be as "friendly" 
as possible (no more support questions! :)

Regards,
Philip Olson.


On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote:

> On Mon, 8 Jul 2002, Philip Olson wrote:
> 
> > philip  Mon Jul  8 02:31:59 2002 EDT
> > 
> >   Modified files:  
> > /phpdoc/en/reference/info/functions ini-set.xml 
> >   Log:
> >   register_globals can't really be set by USER with ini_set().
> 
> The documentation doesn't match the source now, which is:
> 
> STD_PHP_INI_BOOLEAN("register_globals", "0",PHP_INI_ALL,
> 
> So I guess we need to fix that too?
> 
> Derick
> 
> >   
> >   
> > Index: phpdoc/en/reference/info/functions/ini-set.xml
> > diff -u phpdoc/en/reference/info/functions/ini-set.xml:1.12 
>phpdoc/en/reference/info/functions/ini-set.xml:1.13
> > --- phpdoc/en/reference/info/functions/ini-set.xml:1.12 Tue Jun 18 08:06:10 
>2002
> > +++ phpdoc/en/reference/info/functions/ini-set.xml  Mon Jul  8 02:31:58 2002
> > @@ -1,5 +1,5 @@
> >  
> > -
> > +
> >  
> >
> > 
> > @@ -975,7 +975,7 @@
> >
> > register_globals
> > "0"
> > -   PHP_INI_ALL
> > +   PHP_INI_PERDIR|PHP_INI_SYSTEM
> >
> >
> > safe_mode
> > 
> > 
> > 
> > -- 
> > PHP Documentation Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> 
> ---
>  Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
>  Frequent ranting: http://www.derickrethans.nl/
> ---
>  PHP: Scripting the Web - [EMAIL PROTECTED]
> All your branches are belong to me!
> SRM: Script Running Machine - www.vl-srm.net
> ---
> 



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] $HTTP_*_VARS deprecation status request

[Philip Olson]

Hello,

Any idea if/when these variables won't be 
created by PHP?

Regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] socket_select() problems?

[Philip Olson]

I only get [0], never [1].  Did about 40 tries.

  latest CVS
  ./configure --enable-sockets

If you need more info, let me know.

Regards,
Philip Olson




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] isset multiple arguments, when?

[Philip Olson]

Hello,

When did isset() allow for multiple arguments, was 
it 4.1.0?  The closed feature request is here:

  http://bugs.php.net/12978

Neither NEWS or it mentions when this feature 
was implemented.

Regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] $_FILES, is there ant bug?

[Philip Olson]

$_FILES has existed since 4.1.0 but was forgotten 
in the release announcement.  Before this, try 
$HTTP_POST_FILES.  So to test:

  print_r($HTTP_POST_FILES);
  http://www.php.net/manual/en/features.file-upload.php

Support options can be read about here:

  http://www.php.net/support

Regards,
Philip Olson


On Mon, 27 May 2002, Sander Roobol wrote:

> Which version of PHP are you running? Versions before 4.1.0 don't have 
> the $_* variables. $_FILES may be an exception, it might be only 
> available in 4.2.0 and later, but I'm not sure about that.
> 
> Sander
> 
> On 2002.05.27 19:47 Daniel CAstro wrote:
> > My code is much more extense than this, but I guess this is the source
> > of my
> > problem.
> > "arquivo" is a member of a form, it is a file type, declared like
> >  > type="file" name="arquivo">...
> > I need to know if there is a file selected or not, that is the reason
> > of the
> > bug.
> > When I run this code, through the form it does not print anything,
> > even when
> > I choose a file on the previous html (html with a form, with an action
> > calling this script...)  My version of PHP is 4.x
> >  >  $nome = $_POST['nome'];
> >  $des = $_POST['des'];
> >  $eng = $_POST['eng'];
> >  $id  = $_POST['id'];
> >  $tabela= $_POST['tabela'];
> >  $tabela_nova  = $_POST['dd_tipo'];
> >  $arquivo  = $_FILES['arquivo']['name'];
> >  //Conexao com BD...
> >  printf("%s",$arquivo);
> > ?>
> > 
> > Why it is happenig???
> > _
> > Daniel Castro ICQ#: 12919017
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > _
> > 
> > 
> > ---
> > O email enviado não tem Vírus
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.365 / Virus Database: 202 - Release Date: 24/5/2002
> > 
> > 
> > 
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> > 
> > 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] php-announce

[Philip Olson]

Hello,

What's the exact protocol behind the announcements 
list?  Usually announcements get posted but not always.  
Looking through news I see:

  4.0.4
  ?
  ?  
  4.0.6 memory limit patch
  a couple of php-gtk announcements
  4.1.0
  4.1.1
  ?
  4.2.0

As you can see, a few are missing.  I'm sure 
4.2.1 is soon on its way but how? who? when? :)

Regards,
Philip Olson




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: list() limitations

[Philip Olson]

> > Aside from saying it works on values for numerical arrays 
> > I can't say much else.  That is intuitive and consistant 
> > to me, not ambiguous.  
> 
> It is :) Since we both already have different views. I
> suggest leaving it; it's not worth the trouble and using the
> array_(keys|values) is the most readable solution.

You can't get off that easily :)  Please tell me why it's 
ambiguous for list to get values from one array and not 
just the values from another.

Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: list() limitations

[Philip Olson]

> The big question is: how would You (Philip,Yasuo) want list
> to behave when it encounters a hash? Do you want to get the
> keys ? Or the values? Or do you want to get the hashed
> element on its own again as key => value ?

My opinion is:
  $foo = array('a' => 'apple', 'b' => 'banana');
  list($a,$b) = $foo;
  print $a; // apple
  print $b; // banana

This would be consistant with how list works with 
numerical arrays.  It gets the values, not the keys.

> No, I don't think it's a good idea. That is why we have
> array_(keys|values), it makes the code readable and it's easy
> to understand.

This is understandable but list() works on values, it does 
this for one type of array but not another.
 
> For me, it would make most sense to have the following:
> 
> list($a, $b) = array('a' => 'apple', b => 'beer');
> 
> var_dump($a);
> array(1) {
>   ["a"]=>
> string(5) "apple"
> }
> 
> I don't think many would share _this_ behaviour.
> 
> All in all I think this would get too ambiguous if we would
> change the behaviour. Unless someone comes with really
> intuitive and useable I examples I don't think it should
> change at all (the list construct).

Aside from saying it works on values for numerical arrays 
I can't say much else.  That is intuitive and consistant 
to me, not ambiguous.  

Regards,
Philip




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: list() limitations

[Philip Olson]

> >   $foo = array('a' => 'apple', 'b' => 'banana');
> >   
> >   // Notice - Undefined offset:  1
> >   // Notice - Undefined offset:  0
> >   list($a,$b) = $foo; 
> 
> Isn't this line should be
> 
> list($a, $b) = array_keys($foo);
> or
> list($a, $b) = array_values($foo);

Sure that works.

> I might miss you point, since it seems we are
> going to make these feature requests bogus.

Why?  list() working with associative arrays 
seems bogus to you?  Please be specific as to 
why this is bad.  Why is requiring keys indices 
to begin at 0 good or necessary? I can't think 
of a case where this will be bad for a php user.
Imho it's intuitive.

Sure it's not a major deal and more pressing 
needs exist but hey, what can I say. :)

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] list() limitations

[Philip Olson]

Hello, the following behavior seems odd:

  $foo = array('a' => 'apple', 'b' => 'banana');
  
  // Notice - Undefined offset:  1
  // Notice - Undefined offset:  0
  list($a,$b) = $foo; 

  // This of course works as expected
  while(list(,$ab) = each($foo)) {
  print $ab;
  }

I recently documented this numerical requirement (starting 
at 0) as a  but find it odd.  This is mentioned as a 
bug in a few places but I can't find any closed reports. 
It's a pretty good feature request, right?

Regards,
Philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Streams are here!

[Philip Olson]

> > Please please please test the following things in particular
> > as I can't compile them or verify them here:
> 
> I can't compile, because it complains about `ptrdiff_t' undeclared in
> main/network.c. I think stddef.h or similar is needed in this file.

this also affects --enable-sockets, please fix soon i'm trying 
to test something ;))

philip


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] new php.net shortcuts

[Philip Olson]

> I would like to start with a basic list though
> to put up as an announcement, and prove that
> this simple thing works too...

Sounds good.  But, start archiving now and in a few 
months enough data will exist to make some useful 
decisions.

> > On a related note, www.php.net needs a nasty popup 
> > that says "Choose a mirror!!!" ;)
> 
> This is for a long time on our TODO list. Actually
> a nice automatic mirror chooser, and advice box
> would be good, and not an annoying popup box IMHO.

This will be a nice system.  Btw, was kidding about 
the popup, sometimes I wonder if anyone gets me :)
Point is, the fear this will bog down www. even more.

Regards,
Philip Olson



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] new php.net shortcuts

[Philip Olson]

> $CUSTOM_SHORTCUTS = array (
>   'ini' => 'configuration',
>   'windows' => 'install.windows',
>   'install' => 'installation'

How about starting an archive of terms posted into 
the php.net search box.  This will make for some 
good data which will eventually provide info to 
expand this feature.

On a related note, www.php.net needs a nasty popup 
that says "Choose a mirror!!!" ;)

Regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP_INI USER|PERDIR|SYSTEM|ALL

[Philip Olson]

it'd be uber cool if this got a response or two ;-)

> Looking through main/main.c it lists many configuration 
> directives as PHP_INI_ALL when in the real world this is 
> not the case.
> 
> For example, register_globals entry is:
> 
> STD_PHP_INI_BOOLEAN("register_globals", "1", PHP_INI_ALL,
>   OnUpdateBool, register_globals, php_core_globals, 
>   core_globals)
> 
> When it behaves more like: PHP_INI_PERDIR|PHP_INI_SYSTEM 
> as PHP_INI_USER cannot change this master value.  Another 
> example is magic_quote_gpc.
> 
> Please share some light on this.  The config documentation 
> will eventually contain this information and simply 
> harvesting the values from main.c does not seem appropriate.  
> Please explain a little about local/master values too :)
> 
> Regards,
> Philip Olson
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP_INI USER|PERDIR|SYSTEM|ALL

[Philip Olson]

Looking through main/main.c it lists many configuration 
directives as PHP_INI_ALL when in the real world this is 
not the case.

For example, register_globals entry is:

STD_PHP_INI_BOOLEAN("register_globals", "1", PHP_INI_ALL,
  OnUpdateBool, register_globals, php_core_globals, 
  core_globals)

When it behaves more like: PHP_INI_PERDIR|PHP_INI_SYSTEM 
as PHP_INI_USER cannot change this master value.  Another 
example is magic_quote_gpc.

Please share some light on this.  The config documentation 
will eventually contain this information and simply 
harvesting the values from main.c does not seem appropriate.  
Please explain a little about local/master values too :)

Regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14131 Updated: include "http" problem

[Philip Olson]

Someone please briefly explain this behavior.  As per the note 
under "remote files" in manual:

  Note:  You can't use remote files in include() and require() 
 statements on Windows.

Why is that?

Regards,
Philip Olson


On 24 Jan 2002 [EMAIL PROTECTED] wrote:

> ID: 14131
> Updated by: sander
> Old Summary: include "http" problem
> Reported By: [EMAIL PROTECTED]
> Status: Bogus
> Bug Type: Scripting Engine problem
> Operating System: Windows Server 2000
> PHP Version: 4.0.6
> New Comment:
> 
> Read the docs. include() and require() do not work on Windows on remote
> files.
> Alternative: readfile()
> 
> 
> Previous Comments:
> 
> 
> [2002-01-24 11:27:25] [EMAIL PROTECTED]
> 
> So why not post that as a solution in the first place ??
> As we and MOST others download pre compiled binaries to use on our full
> production sites.
> 
> 
> 
> [2002-01-24 11:24:51] [EMAIL PROTECTED]
> 
> Still is a configuration error...
> You must enable remote includes at compile time.
> 
> 
> 
> [2002-01-24 11:21:13] [EMAIL PROTECTED]
> 
> PHP on IIS does not have external includes they just do work. We we
> posted this before we were told it is a config error, it is not it is
> an error loclal includes work but not http:// includes even with php as
> a module on apache.
> 
> 
> 
> [2001-11-20 03:13:58] [EMAIL PROTECTED]
> 
> This is most likely a configuration problem. Please ask such questions
> on [EMAIL PROTECTED]
> 
> Bogus
> 
> 
> 
> [2001-11-19 21:34:26] [EMAIL PROTECTED]
> 
> include ("http://www.somesite.com/somepage.html";);
> 
> Worked perfect on our unix box and our win98 machines but when we
> installed PHP on our Windows server it no longer worked and tottaly
> ignored the include unless we used the path instead like.
> 
> include ("somepage.html"); 
> 
> [EMAIL PROTECTED]
> 
> 
> 
> 
> 
> Edit this bug report at http://bugs.php.net/?id=14131&edit=1
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] FeatureRequest for PHP5

[Philip Olson]

> > It would be great if it was possible to have CONSTANTS
> > of types like as Arrays or Objects.

> You can already use constant arrays such as array(1, 2, 3) 
> as constants.

Maybe some day ;)

 define('BLAH', array(4,5));
   Warning: Constants may only evaluate to scalar values

You can serialize or implode the values ... This is a 
decent feature request, submit feature requests to:

 http://bugs.php.net

regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP] Re: [PHP-DEV] Re: strtok bug

[Philip Olson]

BC was broken, this happens sometimes.  The majority of the PHP Dev team
agrees that strtok() should be POSIX compliant, so it is now, and forever
will be.

Not being in NEWS/Changelog was an oversight/error, nobody is perfect.
This not happening in the future is a desire of everyone.  Also, it'll be
nice when every BC break is clearly documented in one place, deprecations
too. Your desires on the matter are shared by all, in that, allowing for
seamless PHP upgrades is a good thing.

Such breaks are very uncommon in the PHP world, you will find that some
members want many more :))  

This is documented now which is as best we can do at this point.  That and
clearly document all BC breaks in the future.  I vow to help on the
documentation end.

Regards,
Philip Olson


On Mon, 14 Jan 2002, Manuel Lemos wrote:

> Hello,
> 
> I don't disagree, but the fact is that doesn't help anybody that used
> the function and relied on its original behaviour that was there for 4
> years.
> 
> As for being POSIX compliant, I don't think that POSIX states anything
> about how PHP functions should behave, so I do not see where is the gain
> of breaking this function, especially when making PHP strtok behave
> exactly like C strtok is absolutely irrelevant I think for 99,9% of PHP
> users because they don't use C in POSIX at all. As a side note, based on
> the Web browser share distribution of the PHP Classes site, I think the
> majority of PHP users come from Windows now, but I may be wrong.
> 
> Anyway, if breaking the behaviour of a long standing function was bad,
> what really made it worse the was fact that who has broken the function,
> did not even have the decency to note down in the NEWS/ChangeLog, so
> whoever plans to upgrade to PHP 4.1.0 could be warned and avoided
> outages due to this silent backwards incompatible change.
> 
> Documenting the new behaviour in the user manual does not help even if
> it was not made much later after releasing PHP 4.1.0 like this change
> that was only documented because there was a bug report much later after
> the change was done. What happens is that careful developers tend to
> take a look in the ChangeLog before installing a new version in a
> production environment to avoid outages and misbehaviour cause by the
> change in the broken function. Since it did not happen even until today,
> nobody is being warned and depending on what the function is used for,
> it may be causing data trashing of site databases until the developers
> realize what happened.
> 
> Don't you have a requirement in the PHP CODING STANDARDS file that makes
> it mandatory for PHP developers to note down important changes? Not
> having such requirement just allows messy development habits to
> jeopardize PHP code quality.
> 
> Before somebody decides to repress my opinion again, notice how I am
> trying to be constructive by suggesting improvements in the quality of
> PHP development process. Now you may put that gun down. :-)
> 
> Regards,
> Manuel Lemos



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] superglobals and bc

[Philip Olson]

> > Now mimicking $_SESSION functionality is another story, eww, maybe that's
> > going too far.
> 
> This can be done by a register_shutdown_function() who registers
> all the vars in $_SESSION, using session_register. That's all :))
> If I can understand this new feature correctly (I never used it).

LOL, no comment :)

> > Regarding the extract() idea, please clarify a little more.
> 
> I think Rasmus referred to the register_globals deprecation
> question, which is another thing IMHO, that need to be documented.

Okay that makes sense.  Was thinking on the lines of a 
serialized constant :)

> There are many "user notes" coming up about using:
> 
> extract($_REQUEST);
> 
> and the like to simluate register_globals. This can
> be a really bad thing sometimes...

Yes it can be.  People will continue to do this, we'll need to 
keep expanding/referring to security.registerglobals:

  http://www.php.net/manual/en/security.registerglobals.php

Regards,
Philip Olson






-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] superglobals and bc

[Philip Olson]

> The only real thing I think you can document on this is that you can't use
> superglobals and expect your scripts to work on older versions of PHP.

true.  We can refer to a faq, one with a hack or two.

> I mean, you could check php_version() and stick in some extract() calls
> for older versions wherever you use the superglobals, but that seems
> rather ugly.

Some really want it, let's define the most efficient/least ugly types of
hacks :)  For example with get, checking phpversion, then appropriatly
defining $_GET = &$HTTP_GET_VARS. And in a function, do: global $_GET. Now
mimicking $_SESSION functionality is another story, eww, maybe that's
going too far.

Regarding the extract() idea, please clarify a little more.

Regards,
Philip Olson




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] superglobals and bc

[Philip Olson]

Many ask "How do I use superglobals yet allow my scripts to work on older 
versions of PHP", is there an official documentable response to this?

Regards,
Philip Olson




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #15012: Cannot load libphp4.so - undefined symbol:uncompress

[Philip Olson]

See this faqt:
  http://www.faqts.com/knowledge_base/view.phtml/aid/5087

Regards,
Philip Olson

> Cannot load /usr/local/apache/libexec/libphp4.so into server:
> /usr/local/apache/libexec/libphp4.so: undefined symbol: uncompress


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #15007 Updated: New superglobals not documented

[Philip Olson]

> > This appears to be a website problem, not a documentation problem. 
> > Searching for '$_SERVER' results in matches for 'server', over 2000 of
> > them.  If this was a documentation problem, zero results would exist.
> > 
> > This is a website problem/feature request.
> 
> Then its both. Superglobals are NOT documented (yet).

If it was documented, will one be able to do a search for _SERVER?
HTTP_SERVER_VARS is searchable.  I'm not familiar with how the
crawling/indexing works.  Ideally the over 2,000 results for 'server'
wouldn't come up for this.

These need to be documented very soon, I'll add them today.  The
variables.predefined restructuring can wait, I believe Kenneth is working
on that.

Regards,
Philip Olson




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Behaviour of $array1 + $array2

[Philip Olson]

Here's an example of related activities (4.1.1):

 '4 a', 2 => '2 a', 'foo' => 'foo a');
  $b = array(4 => '4 b', 1 => '1 b', 'foo' => 'foo b');

  $c['plus'] = $a + $b;
  $c['merge']= array_merge($a,$b);
  $c['merge_recursive']  = array_merge_recursive($a,$b);
  $c['concat']   = $a . $b;

  print_r($c);
?>

The behavior of . both seems weird yet mostly makes sense too.  I agree,
the use of '+' needs to be documented.  Documented with
similarities/differences between array_merge and array_merge_recusive.  
Some obvious differences can be seen through the above example, who will
document this and where? :)

I just reported bug #14990 on array_merge_recursive which may be of
interest.  Without further ado, here's the output from the above code:

Array
(
[plus] => Array
(
[4] => 4 a
[2] => 2 a
[foo] => foo a
[1] => 1 b
)

[merge] => Array
(
[0] => 4 a
[1] => 2 a
[foo] => foo b
[2] => 4 b
[3] => 1 b
)

[merge_recursive] => Array
(
[0] => 4 a
[1] => 2 a
[foo] => Array
        (
[0] => foo a
[1] => foo b
)

[2] => 4 b
[3] => 1 b
)

[concat] => ArrayArray
)


Regards,
Philip Olson




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14420 Updated: is_file prints "stat failed .."message

[Philip Olson]

On 13 Dec 2001 [EMAIL PROTECTED] wrote:

> Same problem appeared with is_dir() function. In this case I think we
> should check is_readable(), is_writable() and is_writeable() functions
> as well.

hello vitali,

it's fixed now.  sterlings commit will be implemented in 4.2.0, from
NEWS:

- Fixed is_dir(), is_writeable(), is_readable(), is_executable(),
  is_link() and is_file() functions to not throw a 'file does not
  exist' warning. (Sterling)

  http://cvs.php.net/co.php/php4/NEWS

patch can be seen here:

  http://cvs.php.net/diff.php/php4/ext/standard/filestat.c?r1=1.82&r2=1.83

for other patches made to filestat.c see:

  http://bonsai.php.net/cvslog.cgi?file=/php4/ext/standard/filestat.c

woohoo! :)

regards,
philip olson


 
> Previous Comments:
> 
> 
> [2001-12-12 11:38:37] [EMAIL PROTECTED]
> 
> This is fixed in CVS. 
> 
> --Jani


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14473 Updated: strtotime wont parse date

[Philip Olson]

just a fyi on why.  strtotime obeys the information found here:

  http://www.gnu.org/manual/tar-1.12/html_chapter/tar_7.html

so, doing strtotime('Twelfth December 2001'); will work.  anyway, fwiw 
there you have it :)

regards,
philip olson

On 12 Dec 2001 [EMAIL PROTECTED] wrote:

> ID: 14473
> Updated by: derick
> Reported By: [EMAIL PROTECTED]
> Status: Open
> Old Bug Type: Date/time related
> Bug Type: Feature/Change Request
> Operating System: Redhat 7.2
> PHP Version: 4.1.0
> New Comment:
> 
> >From the manual:
> 
> strtotime --  Parse about any English textual datetime description into a UNIX 
>timestamp
> 
> please note it says any, not all.
> 
> Moving this to a feature request.
> 
> Derick
> 
> Previous Comments:
> 
> 
> [2001-12-12 18:36:30] [EMAIL PROTECTED]
> 
> strtotime('12th December 2001')
> 
> returns -1
> 
> The 'th' after the number causes the problem, but this is a perfectly acceptable 
>date representation and should be recognised I believe.
> 
> 
> 
> 
> 
> 
> 
> Edit this bug report at http://bugs.php.net/?id=14473&edit=1
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14367: browscap not well documented

[Philip Olson]

Currently browscap.ini is a front by Cyscape to promote browserHawk. In
fact, they often diss on browscap.ini on their website and haven't updated
the file since Feb 2000.  Back in the good 'ol days it was updated and
made more sense, not anymore.

A feature request to not use browscap.ini at all exists here:

  http://bugs.php.net/bug.php?id=4856

This is a very nice feature request :)

Regards,
Philip Olson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14296 Updated: Undeclared variables and isset()

[Philip Olson]

E_NOTICE:
http://www.php.net/manual/en/phpdevel-errors.php#internal.e-notice
http://www.php.net/manual/en/configuration.php#ini.error-reporting

The following won't create a E_NOTICE level error when $var is not set:

  if (isset($var) && $var == 'foo') {
echo 'I Love to foo';
  }

Could also use a @ but it's not as cool imho :)

  if (@$var == 'foo') {
echo 'I love to foo';
  }

So as suggested, this depends on your particular settings.  Also see the
error_reporting() function.

regards,
Philip Olson


On 30 Nov 2001 [EMAIL PROTECTED] wrote:

> ID: 14296
> Updated by: hholzgra
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Feedback
> Bug Type: Variables related
> Operating System: Win2k
> PHP Version: 4.0.6
> New Comment:
> 
> looks like you have set error_reporting to E_ALL
> while you had E_ALL & ~E_NOTICE before?
> 
> maybe by using php.ini-recommended as template
> for php.ini with 4.0.6 while using php.ini-dist
> for the former versions?
> 
> Previous Comments:
> 
> 
> [2001-11-30 04:15:44] [EMAIL PROTECTED]
> 
> 
> SYSTEM:
> I use PHP 4.0.6 on Win2k pro with Apache 1.3.22 win
> Loaded modules don't seem to make a difference for the described behaviour.
> 
> DESCRIPION:
> Let's say we have a PHP script, the retrieves some variables via HTTP post or get. 
>And the variables, passed to the script, have different names each time.
> Usually we would use "isset($variable)" to check if it exists. In most cases we need 
>to check the content of the variable too. So it would be nice to do that in one step.
> 
> The script of the following examples retrieved $var1 or $var or both of them via 
>HTTP.
> 
> EXAMPLE 1:
> // This would be the usual way i guess
> if(isset($var1)){
>   ...
> }
> if(isset($var2)){
>   ...
> }
> 
> EXAMPLE 2:
> // This has been possible with PHP 3.xx - 4.0.5
> // without previously checking for existence 
> // of $var1/$var2
> if($var1 == "something"){
>   ...
> }
> if($var2 == "anything"){
>   ...
> }
> 
> EXAMPLE 3:
> // With PHP 4.0.6 we would have to do this:
> if(!isset($var1)){ // is NOT declared?
>   $var1 = "";
> }
> if(!isset($var2)){ // is NOT declared?
>   $var2 = "";
> }
> // first we had to declare them, now we can use them
> if($var1 == "something"){
>   ...
> }
> if($var2 == "anything"){
>   ...
> }
> 
> 
> I wonder if this new behaviour is a bug or a feature?
> Or why can't I find info about it in the changes list if it's a feature?
> 
> Please send your answer to: [EMAIL PROTECTED]
> 
> Thank you!
> 
> Volker Puttrich
> 
> 
> 
> 
> 
> 
> Edit this bug report at http://bugs.php.net/?id=14296&edit=1
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #10172 Updated: get_class() doesn't return lowercasefor DomX objects

[Philip Olson]

iirc, sometime in the future php will have case-sensitive function/class
names.  If so, how about waiting to make a change then?  Is this what you
are suggesting, Markus?

philip


On Fri, 23 Nov 2001, Markus Fischer wrote:

> On Thu, Nov 22, 2001 at 05:11:19PM -0500, Colin Viebrock wrote : 
> > Except, that would entail making function names and class names 
> > case-sensitive, which they aren't now.  That is much more of a major
> > change to the language (with huge compatability issues) than what
> > I am proposing.
> 
> Hey, I didn't say it would make sense to do this now ;-)
> 
> - Markus
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] bug status definition request

[Philip Olson]

hi,

What's the difference between open, feedback and analyzed?  Seems most
discussions leave the bug status as open.

philip



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #13889: FORM variables not passed with php.ini-optimized

[Philip Olson]

i am guessing this is a register_globals issue.  see:

 http://www.php.net/manual/en/configuration.php#ini.register-globals
 http://www.php.net/manual/en/security.registerglobals.php

regards,
Philip Olson

On 31 Oct 2001 [EMAIL PROTECTED] wrote:

> From: [EMAIL PROTECTED]
> Operating system: Windows 2000
> PHP version:  4.0.6
> PHP Bug Type: PHP options/info functions
> Bug description:  FORM variables not passed with php.ini-optimized
> 
> FORM variables are not passed when php.ini-optimized is used for
> C:\WINNT\php.ini.
> 
> The workaround is to use php.ini-dist instead.
> -- 
> Edit bug report at: http://bugs.php.net/?id=13889&edit=1
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] karma request - phpweb

[Philip Olson]

> > Hi!  I request karma for module phpweb.  Am working with jmcastagnetto on
> > user notes where Voting and "User Moderation" will be implemented.  And
> > will most likely find other things to do, albeit nothing major (yet?).
> 
> Colin has already done this with the PHP-GTK Manual.

i've seen the voting, but not the 'user maintenance' system.  will email
colin and see how he's doing :)

philip

ref: http://marc.theaimsgroup.com/?l=phpdoc&m=99618446902193


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] karma request - phpweb

[Philip Olson]

Hi!  I request karma for module phpweb.  Am working with jmcastagnetto on
user notes where Voting and "User Moderation" will be implemented.  And
will most likely find other things to do, albeit nothing major (yet?).

Warm Regards,
Philip Olson

user: philip


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]