mimeview/php.py don't display the php file

[dna]

mimeview/php.py dont disply the php file.

the only output is:

Line	 
1 	X-Powered-By: PHP/5.0.4

[dna]

using: [1804]

last working revision was:

source:/trunk/trac/mimeview/php.py#1620

[xris]

the solution suggested in #1679 doesn't work for me.

[Christian Boos]

I was able to reproduce the bug… let me some time to look at it

[Christian Boos]

The main issue should be fixed in [1810]. As noted there, I think there's still a small visual glitch however.

[Matthew Good]

Well, PHP4 worked fine before, but now is broken with [1810]. Using PHP5 highlighting doesn't seem to work properly here in either case.

[Christian Boos]

Well, don't change things to fast: I tested r1810 with PHP/4.3.3 on SuSE Linux 9.0 and it definitely works for me :)

Notice what happened in r1764:

--- trunk/trac/mimeview/php.py	(revision 1763)
+++ trunk/trac/mimeview/php.py	(revision 1620)
@@ -66,11 +66,14 @@
 
         np = NaivePopen(cmdline, content, capturestderr=1)
         if np.errorlevel or np.err:
-            err = 'Running (%s) failed: %s, %s.' % (cmdline, np.errorlevel, np.err)
+            err = 'Running (%s) failed: %s, %s.' % (cmdline, np.errorlevel,
+                                                    np.err)
             raise Exception, err
         odata = np.out
 
         # Strip header
-        beg = odata.find('<code>')
-        odata = PhpDeuglifier().format(odata[beg:])
-        return '<div class="code-block">' + odata + '</div>'
+        html = PhpDeuglifier().format(odata.splitlines()[1])
+        for line in html.split('<br />'):
+            # PHP generates _way_ too many non-breaking spaces...
+            # We don't need them anyway, so replace them by normal spaces
+            yield line.replace('&nbsp;', ' ')

odata (np.out) is processed very differently…

• r1620 (and r1810): np.out is a sequence of lines (one for each original PHP source code line)
• r1763: apparently, from the splitlines()[1], there's the assumption that there are only 2 lines of output, one for the header, the other for the highlighted source code.

Maybe both outputs are possible, but I don't know what would trigger the difference (maybe a build configuration switch for PHP?)

[Christian Boos]

Here's what I get for echo '<?php echo "hello" ?>' | php -s with two versions of PHP:

• PHP 4.3.10

  <code><font color="#000000">
  <font color="#0000BB">&lt;?php </font><font color="#007700">echo </font><font color="#DD0000">"hello" </font><font color="#0000BB">?&gt;<br /></font>
  </font>
  </code>
  

• PHP 4.3.3

  Content-type: text/html
  X-Powered-By: PHP/4.3.3
  
  <code><font color="#000000">
  <font color="#0000BB">&lt;?php </font><font color="#007700">echo </font><font color="#DD0000">"hello" </font><font color="#0000BB">?&gt;<br /></font>
  </font>
  </code>
  

So it appears that the first output style is handled well by r1764 and the second by r1810…

The correct thing to do I guess is to be prepared for any of those styles and take either the second or fourth line of output.

(What is strange is that the current bug report seems to be similar to the second output style (4.3.3), but indicates a PHP version of 5…)

[Christopher Lenz]

cboos:

apparently, from the splitlines()[1], there's the assumption that there are only 2 lines of output, one for the header, the other for the highlighted source code.

The assumption is that the actual content is all on the second line, which is true for your first example (PHP 4.3.10) and works on my system. The difference to the second example is only that PHP writes HTTP headers before the body. The content we want to extract is still all on the second line of the "body".

So I'd suggest reverting to the algorithm in [1764], but stripping HTTP headers (and the empty line terminating the headers) if they are present.

[xris]

you guys do know that you can run php with the -q option to hide those http headers, right?

[Matthew Good]

I've tried PHP 4.3.10 which cboos already mentioned.

Runnnig PHP 5.0.4 from the command line produces:

Content-type: text/html
X-Powered-By: PHP/5.0.4

<code><span style="color: #000000">
<span style="color: #0000BB">&lt;?php </span><span style="color: #007700">echo </span><span style="color: #DD0000">"hello" </span><span style="color: #0000BB">?&gt;<br /></span>
</span>

Note that they now use <span> to do the coloring, so the Deuglifier will no longer work for PHP 5.

However, the weirdest part with PHP 5 is that when I use it in Trac I don't even get the highlighted file, but instead the contents of trac.cgi are displayed in the mimeviewer. My assumption is that the CGI environment variables are inherited in the PHP process, and that they are trying to process the contents of the requested page, which happens to take priority over stdin.

[Matthew Good]

xris, thanks for the tip on the -q option.

Unfortunately it's not documented in the php man page.

[Christopher Lenz]

I guess we could use the value of the X-Powered-By header to differentiate between PHP 4 and 5 for the deuglifying… or just duplicate all the rules.

Evil that PHP5 displays trac.cgi though; not sure what we can do about that… disable inheritance of CGI env vars somehow?

[Matthew Good]

Well, there are two versions of the PHP executable. One for CGI and one for the CLI. The CGI version prints the HTTP headers and will try to highlight a file based on the CGI environment variables. So to avoid problems with the CGI version, Trac now requires using the more appropriate CLI version. PHP provides builds of both in their Windows ZIPs, and Linux vendors seem to have the two versions provided in separate packages that can both be installed.

To prevent confusion from the "X-Powered-By" header seen above, and prevent printing the contents of the "trac.cgi" instead of the requested file [1813] displays a descriptive error message if you try to use the CGI version of the PHP executable.