ini-Option „highlight.bg“ wird ignoriert / *.phps unter PHP-CGI

[Mathias Brodala]

Hallo.

Da weder meine Mail an eine der PHP-Mailinglisten durchgekommen noch mein Debian-Bugreport bisher beantwortet wurde, möchte ich doch einmal hier nachfragen, um einen Konfigurationsfehler meinerseits auszuschließen:

Wird bei euch die ini-Option „highlight.bg“ anerkannt und umgesetzt?

Ich habe diese wie folgt in meiner php.ini gesetzt:

; Colors for Syntax Highlighting mode.  Anything that's acceptable in
; <span style="color: ???????"> would work.
highlight.string  = #FFA0A0
highlight.comment = #87CEEB
highlight.keyword = #CD5C5C
highlight.bg      = #333333
highlight.default = #98FB98
highlight.html    = #ffffff

Nach einem Serverneustart kontrollierte ich nun per phpinfo(), ob die Einstellung übernommen wurde, was der Fall zu sein scheint. Doch tatsächlich ist der Hintergrund für *.phps-Dateien grundsätzlich Weiß. Alle anderen Optionen wurden jedoch korrekt übernommen.

Kann dies hier jemand nachvollziehen oder hat gar einen Tipp, wo das Problem seine Wurzel haben könnte? Lokal verrichtet PHP 5.2.0 auf einem Apache 2.2.3 in Modulform sein Werk.

Versuche ich, auf CGI-Betrieb umzustellen, muss ich einen Symlink unter /usr/local/lib/php.ini nach /etc/php5/apache2/php.ini erstellen. Doch *.phps-Dateien werden nun nicht mehr interpretiert sondern zum Download angeboten. Normale PHP-Scripte werden dagegen problemlos interpretiert. Meine Konfiguration:

ScriptAlias /cgi-bin/ /usr/local/bin/
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Action application/x-httpd-php /cgi-bin/php
Action application/x-httpd-php-source /cgi-bin/php -s

Ist hieran etwas fehlerhaft? Die letzte Zeile habe ich nur auf Gutdünken hinzugefügt; ohne sie ist das Resultat identisch.

Gruß, Mathias

[Mathias Brodala]

Hallo nochmal.

Meine Konfiguration:

ScriptAlias /cgi-bin/ /usr/local/bin/
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Action application/x-httpd-php /cgi-bin/php
Action application/x-httpd-php-source /cgi-bin/php -s

Ist hieran etwas fehlerhaft? Die letzte Zeile habe ich nur auf Gutdünken hinzugefügt; ohne sie ist das Resultat identisch.

Nicht ganz, wie mir ein Serverneustart nun offenbart hat:

Syntax error on line 5 of /etc/apache2/mods-enabled/php5-cgi.load:

unrecognized option '-s'

Dies ist so also nicht vorgesehen.

Einen schönen Freitag noch.

Gruß, Mathias

[dedlfix]

echo $begrüßung;

Action application/x-httpd-php-source /cgi-bin/php -s
Syntax error on line 5 of /etc/apache2/mods-enabled/php5-cgi.load:
unrecognized option '-s'
Dies ist so also nicht vorgesehen.

Action erwartet ja auch nur zwei Parameter, nicht drei. Anführungszeichen werden auch nicht funktionieren, wenn ich mir diesen News-Faden ansehe. Auch dieser hat es nicht hinbekommen. Da er aber nicht geschrieben hat, wie bei ihm genau "Batch-Datei hat nicht funktioniert" ausgesehen hat, wäre das vielleicht noch einen Versuch wert.

echo "$verabschiedung $name";

[Mathias Brodala]

Hallo dedlfix.

Action application/x-httpd-php-source /cgi-bin/php -s
Syntax error on line 5 of /etc/apache2/mods-enabled/php5-cgi.load:
unrecognized option '-s'
Dies ist so also nicht vorgesehen.

Action erwartet ja auch nur zwei Parameter, nicht drei. Anführungszeichen werden auch nicht funktionieren, wenn ich mir diesen News-Faden ansehe.

Kann ich bestätigen.

Auch dieser hat es nicht hinbekommen. Da er aber nicht geschrieben hat, wie bei ihm genau "Batch-Datei hat nicht funktioniert" ausgesehen hat, wäre das vielleicht noch einen Versuch wert.

Ändert leider auch nichts. Das minimale Script, abgelegt unter /usr/local/bin/phps:

#!/bin/sh  
  
/usr/local/bin/php -s $@

Zwar werden hierdurch die *.phps-Dateien nicht mehr zum Download angeboten, dafür aber nicht mehr gefunden (404), obwohl physikalisch existent.

Mir scheint, dass der Einsatz von „application/x-httpd-php-source“ für CGI-PHP überhaupt nicht vorgesehen war. Reichlich sinnfrei, aber naja.

Einen schönen Freitag noch.

Gruß, Mathias

[dedlfix]

echo $begrüßung;

Das minimale Script, abgelegt unter /usr/local/bin/phps:

#!/bin/sh

/usr/local/bin/php -s $@

>   
> Zwar werden hierdurch die \*.phps-Dateien nicht mehr zum Download angeboten, dafür aber nicht mehr gefunden (404), obwohl physikalisch existent.  
  
Da scheint mir was mit den Pfaden nicht zu stimmen. Lass das Script doch mal ausgeben, wo es ist (pwd) und was es übergeben bekommt ($@). z.B. so:  
  
~~~sh
#!/bin/sh  
echo "Content-Type: text/plain"  
echo ""  
pwd  
echo "$@"

echo "$verabschiedung $name";

[Mathias Brodala]

Hallo dedlfix.

Das minimale Script, abgelegt unter /usr/local/bin/phps:

#!/bin/sh

/usr/local/bin/php -s $@

> >   
> > Zwar werden hierdurch die \*.phps-Dateien nicht mehr zum Download angeboten, dafür aber nicht mehr gefunden (404), obwohl physikalisch existent.  
>   
> Da scheint mir was mit den Pfaden nicht zu stimmen. Lass das Script doch mal ausgeben, wo es ist (pwd) und was es übergeben bekommt ($@). z.B. so:  
>   
> ~~~sh

#!/bin/sh  

> echo "Content-Type: text/plain"  
> echo ""  
> pwd  
> echo "$@"

Nützt nicht viel, da ja keinerlei Ausgabe davon im Browser erscheint, sondern wie gesagt nur meine 404-Fehlerseite. Auch eine Logausgabe in /tmp führt zu keinem Ergebnis; es ist, als würde das Script überhaupt nicht ausgeführt. Alle Rechte sind jedoch korrekt gesetzt.

Einen schönen Freitag noch.

Gruß, Mathias

[Dennis]

Hi Mathias,

Nützt nicht viel, da ja keinerlei Ausgabe davon im Browser erscheint, sondern wie gesagt nur meine 404-Fehlerseite. Auch eine Logausgabe in /tmp führt zu keinem Ergebnis; es ist, als würde das Script überhaupt nicht ausgeführt. Alle Rechte sind jedoch korrekt gesetzt.

Dann hast du irgendwo anders einen Fehler reingebaut, ich kann dir bestätigen, dass folgendes funktioniert:

ScriptAlias /wrapper/ /var/www/example.org/wrapper/  
  
AddType application/x-httpd-php5 .php  
Action application/x-httpd-php5 /wrapper/php5-starter  
  
<Directory /var/www/example.org/wrapper>  
  Options ExecCGI  
</Directory>

php5-starter ist dabei folgendes Script:

#!/bin/bash  
  
exec /usr/local/bin/php5-cgi /var/www/example.org/htdocs$1

Ich habe jetzt gerade mal ausprobiert, ob das auch klappt, wenn ich -s mit anhänge. Es ist mir nicht gelungen, dass mit der php5-cgi zu schaffen, wenn ich aber PHP CLI verwende, dann klappt es:

#!/bin/bash  
  
echo "Content-Type: text/html"  
echo ""  
exec /usr/local/bin/php5 -s /var/www/example.org/htdocs/index.php

Ist eigentlich sowieso viel besser so, weil man nun noch ein HTML Gerüst drum packen kann - die Ausgabe von PHP ist nämlich nur der <code>-Block ohne was drumrum.

Versuche ich jetzt allerdings beim exec das /index.php durch $1 zu ersetzen, dann funktioniert es nicht mehr... Nehme ich aber php5-cgi und einfach $1 statt /index.php, dann funktioniert es.

Kann man PHP CLI nicht einfach mit $1 den Pfad geben? *grübel* Vielleicht hab ich auch grade nur irgendwo einen Denkfehler drin ;-)

Jedenfalls habe ich gerade noch festgestellt, dass wenn ich statt $1 einfach $PATH_INFO nehmen, dass es dann wie gewünscht funktioniert und es werden mir sämtliche Dateien im Quelltext angezeigt, wie im Apache definiert (hier: .php).

Viele Grüße aus Kanada,
  ~ Dennis.

[dedlfix]

echo $begrüßung;

Kann man PHP CLI nicht einfach mit $1 den Pfad geben?

$1 ist ein vom Apachen übergebener Parameter. Das wird nur der Dateiname sein und der aktuelle Pfad wird nicht mit dem der Datei übereinstimmen.

echo "$verabschiedung $name";

[Dennis]

Hi dedlfix,

$1 ist ein vom Apachen übergebener Parameter. Das wird nur der Dateiname sein und der aktuelle Pfad wird nicht mit dem der Datei übereinstimmen.

Genau, davon bin ich auch ausgegangen, aber warum existiert dann folgender Unterschied bei entsprechendem Wrapper-Script:

a) php-cgi /path/document/root/$1
  b) php-cli /path/document/root/$1

Im ersten Fall klappt alles wie gewünscht, im zweiten Fall scheint bash das $1 nicht bzw. durch einen leeren String zu ersetzen, wodurch dann eine Fehlermeldung kommt, dass /path/document/root/ keine (PHP-) Datei ist.

Viele Grüße aus Kanada,
  ~ Dennis.

[Mathias Brodala]

Hallo Dennis.

Nützt nicht viel, da ja keinerlei Ausgabe davon im Browser erscheint, sondern wie gesagt nur meine 404-Fehlerseite. Auch eine Logausgabe in /tmp führt zu keinem Ergebnis; es ist, als würde das Script überhaupt nicht ausgeführt. Alle Rechte sind jedoch korrekt gesetzt.

Dann hast du irgendwo anders einen Fehler reingebaut, ich kann dir bestätigen, dass folgendes funktioniert:

Alles schön und gut aber im Endeffekt nur Klimmzüge und auch nicht sonderlich flexibel. (Aber dennoch danke für die Scripting-Tipps.)

Was mich nun noch interessiert: hast du einmal versucht „highlight.bg“ einen anderen Wert zuzuweisen? Funktioniert dies bei dir?

Einen schönen Samstag noch.

Gruß, Mathias

[Dennis]

Hi Mathias,

Was mich nun noch interessiert: hast du einmal versucht „highlight.bg“ einen anderen Wert zuzuweisen? Funktioniert dies bei dir?

Habe ich noch nicht probiert, zumal ich die suPHP Kombination verwende, da einfach sehr komfortabel zu administrieren. Wobei suPHP letztendlich natürlich auch auf CGI hinausläuft.

Ich habe allerdings neulich erst irgendwo in einer Mailliste eine Nachricht gelesen, wo jemand das gleiche Problem hatte wie du... ich finde es nur grade nicht wieder :-\ Jedenfalls wurde es dort als Bug abgetan.

Viele Grüße aus Kanada,
  ~ Dennis.

[Mathias Brodala]

Hallo Dennis.

Was mich nun noch interessiert: hast du einmal versucht „highlight.bg“ einen anderen Wert zuzuweisen? Funktioniert dies bei dir?

Habe ich noch nicht probiert, zumal ich die suPHP Kombination verwende, da einfach sehr komfortabel zu administrieren. Wobei suPHP letztendlich natürlich auch auf CGI hinausläuft.

Also ist auch hier kein *.phps nutzbar, richtig?

Ich habe allerdings neulich erst irgendwo in einer Mailliste eine Nachricht gelesen, wo jemand das gleiche Problem hatte wie du... ich finde es nur grade nicht wieder :-\ Jedenfalls wurde es dort als Bug abgetan.

Immerhin bin ich damit also nicht der Einzige, danke. Wenn du diesen Beitrag finden könntest, wäre ich dir allerdings dankbar.

Viele Grüße aus Kanada,

Ebenso aus good olde Germany.

Einen schönen Dienstag noch.

Gruß, Mathias