Devon,
You should be able to search bug db...
Devon O'Dell wrote:
> Instead of telling me to read the source about how PHP/Zend works,
> how about pointing to where the problem is with .phps. Here's the
I've already pointed out one mail. Encoding.
You should be able to find bug report that I've bogusified probably.
IIRC, try use ob_gzhandler enabled php and phps.
There may be other issues, but I don't remeber them now.
> If it is a phps, run highlight_file. Theoretically, there is absolutely
> no difference between highlight_file and a .phps script. If not,
> execute the script.
>
> To illustrate this, we'll jump into the PHP_FUNCTION(highlight_file)
> which calls highlight_file() with the filename and ini config struct.
> This function is defined in zend_language_scanner.l, opens the
> file for scanning, and sends control to zend_highlight() which does
> the rest.
>
> It's the same thing.
$ ls
a.php
$ cp a.php a.phps
and file created as follows has queite different.
<?php show_source('a.php'); ?>
The first wouldn't work with output buffer, the latter works with
output buffer. The latter also can set appropriate header or convert
char encodings appropriately if needed.
I was looking the code long time ago, so I don't remember the details
about buffer problem at all. It could be easy one to fix.
>
> Just to be fair, I'd ask what people are thinking about this "feature"
> now, is anyone else still +anything about it? Additionally, if you
> are + about it, is the ?HIGHLIGHT_FORMAT check decent?
I don't like to see new feature for phps, but I don't care much anyway.
I prefer extended show_source() only, though. I just don't want to send
false message to users by adding new feature to phps. User may think
phps works _correctly_ always.
I suggest fix buffer issue at least if you would like to change phps.
--
Yasuo Ohgaki
>
> Devon
>
> Yasuo Ohgaki wrote:
>
>> This msg may be sent twice....
>>
>> Devon O'Dell wrote:
>> > I wonder if you understand that highligh_file() *is* a call to the
>> > *same* function that provides .phps files with functionality.
>> > By adding line numbers to this function, we are automatically
>> > adding them to .phps free of charge. Doesn't break anything or
>> > make anything less secure.
>> >
>> > The only security implications of .phps are user related and are
>> > also inherent in files shown with highlight_file.
>> > I *really* have no clue about why you say it's half broken. It
>>
>> Read source and understand how things are sent from PHP/Zend,
>> research issues related to it. IIRC there should be at least one bug
>> report in what condition phps does not work well.
>>
>> I vote -1 for changing/adding phps feature.
>> In other words, no x-application/x-httpd-php-source-with-line-number or
>> like.
>>
>> BTW, if you would like to add extra option to highlight_file(), etc.
>> My vote is 0. People should use highlight_file() instead of phps,
>> anyway. With PHP level, we can forget all issues related to phps.
>>
>>
>> > works fine (except for that extra line number thing, but that's no
>> > real problem I'm sure -- the extra line number is also *not*
>> > evident in files highlighted by highlight_file() as I don't think
>> > you understood) and, if it is not supported by your host, a simple
>> > call to highlight_file() is the *exact same thing*.
>> >
>> > Nowhere in my code is there a regex.
>>
>> It's not the point, user can do that if they would like to add line
>> numbers.
>>
>> I really don't care much about this issue wheather there is yet
>> another half broken phps with
>> x-application/x-httpd-php-source-with-line-number, I'm just suggesting
>> having one more half broken feature is not nice.
>>
>> >
>> > I mean, use highlight_file or .phps or whatever, you're advocating
>> > the use of the *exact same functions* in the end. They all
>> > eventually break down to zend_highlight().
>>
>> It's not about the issue calling the same function eventually or not.
>>
>> Again,
>>
>> Research how things should be sent from PHP/Zend. With PHP level, e.g.
>> with scripting, we can forget all issues related to phps.
>>
>> --
>> Yasuo Ohgaki
>
>
>
>
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
