Merkwürdiger php-Fehler

Das Skelett ist mit dem Plugin-Wizard von Dokuwiki erzeugt - die 
fehlende ?> - Klammer ist  original so. Sie einzufügen verschiebt nur 
die Zeilennummer, auf der php auf die Schnauze fällt.

Das Weglassen der ?> - Klammer scheint ihm egal zu sein. Ich habe heute 
ein anderes kleines Plugin gebaut, ebenfalls mit generiertem Skelett und 
fehlenden Klammern in zwei Quellfeils - das funktioniert prächtig...

Patrick schrieb:
> Ich vermute mal, dass sich der Interpreter am ?> in Zeile 40
> verschluckt.

Die Vermutung war gut. Wenn man eins von beiden Zeichen raus nimmt, oder 
ein Blank dazwischen packt, ists weg.

Sowas habe ich in 40 Jahren Programmiererei nicht erlebt. Was ist das 
für eine elende Schrottsprache...

Hat jemand PHP 5.4 oder 5.5 greifbar und kann mal probieren, ob die 
Gurke damit auch auftritt?

Für die 5.3, die ich hier auf Ubuntu 12.04 habe, nehmen sie keine 
Bugreports mehr an.

Es reicht schon, diese Zeile irgendwo einzufügen:

1

// $this->Lexer->addSpecialPattern('<smallcaps.*?>', $mode, 'plugin_smallcaps_syntax');

Super... Ich mach einen Bugreport.

Das Ganze läßt tief blicken, wie die ganze Kiste zusammengehackt ist. 
Kein Wunder, daß PHP bei Ganoven so beliebt ist. Auf den Logs meines 
Servers finden sich Seitenweise Einbruchsversuche gegen phpmyadmin.

Die Kerle haben tatsächlich die Stirn, das als "not a bug" mit Verweis 
auf die Dokumentation abzuweisen.

Wirklich unglaublich.

Uhu Uhuhu schrieb:
> Wirklich unglaublich.

Nun, wenn es tatsächlich so in der Dokumentation steht, ist es nicht 
unglaubich, sondern die einzig logische Konsequenz, dich auf jene zu 
verweisen. Dass man diese implementierung für Unschön erachten kann, ist 
natürlich eine andere Geschichte.

vn nn schrieb:
> Nun, wenn es tatsächlich so in der Dokumentation steht, ist es nicht
> unglaubich, sondern die einzig logische Konsequenz, dich auf jene zu
> verweisen.

Ist das die neuste Bugfix-Technologie? So kann man alles abbügeln und 
hinterher wundern sich die Leute, warum in der Gebrauchsanweisung zur 
Mikrowelle steht, daß man keine nassen Katzen damit trocknen darf...

Uhu Uhuhu schrieb:
> Die Vermutung war gut. Wenn man eins von beiden Zeichen raus nimmt, oder
> ein Blank dazwischen packt, ists weg.

Hast du denn mal

1

$this->Lexer->addSpecialPattern('<smallcaps.*?'.'>', $mode, 'plugin_smallcaps_syntax');

Probiert?

Uhu Uhuhu schrieb:
> Was ist das für eine elende Schrottsprache...

Ja C ist auch so eine Schrottsprache, nicht mal Helloworld klappt da ;-P

1

printf("\helloworld\");

Mein Bugreport wurde frecherweise abgelehnt!

Uhu Uhuhu schrieb:
> phpmyadmin

Was hat ein Userprogramm den nun wieder mit der Sprache zu tun...

Nachtrag:
gedit unter Linux hebt das sogar derart hervor, dass man den "Fehler" 
sogar optisch hervorgehoben sieht.

Uhu Uhuhu schrieb:
> warum in der Gebrauchsanweisung

Ja weil die ständig Bugreports bekommen "Katze lässt sich nicht 
trocknen" schreiben die Das einfach in die Doku anstelle das mal zu 
"fixen"... komische Logik.

Läubi .. schrieb:
> Was hat ein Userprogramm den nun wieder mit der Sprache zu tun...

Ganz einfach: mit einer Schrottsprache, wie PHP, muß man die 
Programmierer nicht extra dazu anhalten, irgend welchen Mist zu 
programmieren - die Sprache legt ihn einfach nahe.

Die Folge sind Programme mit Sicherheitslücken im Dutzend billiger und 
die Ganove freuen sich...

Läubi .. schrieb:
> Uhu Uhuhu schrieb:
>> warum in der Gebrauchsanweisung
>
> Ja weil die ständig Bugreports bekommen "Katze lässt sich nicht
> trocknen" schreiben die Das einfach in die Doku anstelle das mal zu
> "fixen"... komische Logik.

Da hast du einfach etwas zu kurz gedacht:
Die Folge der Methode "Der letzte Schrott ist schon in Ordnung, wenn er 
nur irgendwo im Kleingedruckten erwähnt ist" sind letztendlich 
Gebrauchsanleitungen der genannten Art. Gesunder Menschenverstand? Wo 
kämen wir denn hin, wenn jeder verlangen würde, die Hose nicht mit der 
Kneifzange anzuziehen...

PHP-Freund schrieb:
> Und was genau ist daran Schrott?
> Wenn ich einen Parser mit nicht eindeutigen Zeichenketten füttere muss

Da hast du das Problem genau erkannt.
PHP hatte (zumindest urprünglich) keinen Parser. Sondern ein "wir 
frickeln uns per String-Suche irgendwas ausführbares zusammen"-Chaos.
Und später musste es halt immer kompatibel bleiben.
Der Rest ist, wie man so schön sagt, Geschichte.

Deshalb wird PHP in Informatik/Compilerbau-Vorlesungen gerne als 
Negativ-Beispiel genommen, weil bei PHP so ziemlich alles falsch gemacht 
worden ist, was sich auch nur irgendwie falsch machen lässt.

Man muss PHP aber zugute halten, dass es sich viel Mühe gibt, das vor 
den Anwendern zu verstecken.


Disclaimer: Fühl dich nicht angegriffen. PHP selbst ist sch****, nicht 
das was PHP-Freunde damit programmieren.

@Ernst: Du hast es auf den Punkt gebracht.

Uhu Uhuhu schrieb:
> Ist das die neuste Bugfix-Technologie? So kann man alles abbügeln und
> hinterher wundern sich die Leute, warum in der Gebrauchsanweisung zur
> Mikrowelle steht, daß man keine nassen Katzen damit trocknen darf...

Bitte was? Dein hinkender Vergleich ändert auch nix dran, dass Dinge, 
die laut Doku so gedacht sind, offensichtlich keine Fehler sind 
(andernfalls würden sie ja nicht in der Doku vermerkt sein).

Uhu Uhuhu schrieb:
> Ganz einfach: mit einer Schrottsprache, wie PHP, muß man die
> Programmierer nicht extra dazu anhalten, irgend welchen Mist zu
> programmieren - die Sprache legt ihn einfach nahe.

Süß.

Uhu Uhuhu schrieb:
> Da hast du einfach etwas zu kurz gedacht:
> Die Folge der Methode "Der letzte Schrott ist schon in Ordnung, wenn er
> nur irgendwo im Kleingedruckten erwähnt ist" sind letztendlich
> Gebrauchsanleitungen der genannten Art. Gesunder Menschenverstand? Wo
> kämen wir denn hin, wenn jeder verlangen würde, die Hose nicht mit der
> Kneifzange anzuziehen...

Nun geht der Zusammenhang deines Geschwafles mit der Problemstellung 
endgültig verloren.

Εrnst B✶ schrieb:
> Da hast du das Problem genau erkannt.
> PHP hatte (zumindest urprünglich) keinen Parser. Sondern ein "wir
> frickeln uns per String-Suche irgendwas ausführbares zusammen"-Chaos.
> Und später musste es halt immer kompatibel bleiben.
> Der Rest ist, wie man so schön sagt, Geschichte.
>
> Deshalb wird PHP in Informatik/Compilerbau-Vorlesungen gerne als
> Negativ-Beispiel genommen, weil bei PHP so ziemlich alles falsch gemacht
> worden ist, was sich auch nur irgendwie falsch machen lässt.
>
> Man muss PHP aber zugute halten, dass es sich viel Mühe gibt, das vor
> den Anwendern zu verstecken.

Bestreitet ja auch keiner (siehe mein erstes Posting). Aber sich zu 
beschweren, dass sie etwas als "not a bug" ablehnen, was so in der Doku 
erwähnt ist (und somit offensichtlich kein Bug ist, wenn auch nicht 
gerade elegant), ist echt lächerlich. Das ganze dann damit zu 
vergleichen, dass man auch keine Katze in die Mikrowelle steckt, setzt 
dem ganzen nur de Krone auf.

vn nn schrieb:
> Nun geht der Zusammenhang deines Geschwafles mit der Problemstellung
> endgültig verloren.

Nicht alles, was DU nicht verstehst, ist Unsinn...

vn nn schrieb:
> Bestreitet ja auch keiner (siehe mein erstes Posting). Aber sich zu
> beschweren, dass sie etwas als "not a bug" ablehnen, was so in der Doku
> erwähnt ist (und somit offensichtlich kein Bug ist, wenn auch nicht
> gerade elegant), ist echt lächerlich.

Na ja, was soll man da noch sagen. Den Kadavergehorsam mit Schöpflöffeln 
gefressen und das dann auch noch von anderen verlangen...

vn nn schrieb:
> Das ganze dann damit zu
> vergleichen, dass man auch keine Katze in die Mikrowelle steckt, setzt
> dem ganzen nur de Krone auf.

Daß du von Vergleich schafelst, zeigt nur, daß du nix begriffen 
hast... Ist aber bei der Grundhaltung auch nicht anders zu erwarten.

Ich teile durchaus die Ansicht, dass PHP keine besonders gute 
Programmiersprache ist.

Nur, wenn man sie so dermaßen nicht leiden kann - warum benutzt man sie 
dann? Ist ja nicht so, dass es keine geeigneten Alternativen gäbe. Zum 
Beispiel Python, Ruby on Rails, Scala zusammen mit dem Lift Framework, 
...

Auch zur Software DokuWiki gibt es genügend Alternativen:
http://de.wikipedia.org/wiki/Liste_von_Wiki-Software

Mark Brandis schrieb:
> Nur, wenn man sie so dermaßen nicht leiden kann - warum benutzt man sie
> dann? Ist ja nicht so, dass es keine geeigneten Alternativen gäbe. Zum
> Beispiel Python, Ruby on Rails, Scala zusammen mit dem Lift Framework,

Ja muß man denn eine Programmiersprache, die man - aus welchen Gründen 
auch immer - gerade benutzt, deswegen gleich super-gut finden? Wenn du 
mal mit einem alten rostigen Klepper von Fahrrad unterwegs bist, weil du 
gerade kein anderes hast, lobst du das Vehikel doch auch nicht in den 7. 
Himmel...

PHP ist definitiv der mit weitem Abstand übelste Hack, der mir in 
Jahrzehnten Softwareentwicklung untergekommen ist. Da wird man doch wohl 
noch "ein gewisses Erstaunen", auch in etwas drastischerer Art, äußern 
dürfen.

Ich konnte mir bis vor einigen Tagen, als ich mit gutem Grund damit 
anfing, schlicht nicht vorstellen, daß es möglich ist, eine derartige 
Anhäufung von gröbsten Designfehlern als weidlich genutztes Werkzeug zu 
etablieren. Ich bin überzeugt, daß sehr viele Internetschwachstellen auf 
diesen Murks zurückzuführen ist - die seitenlangen Logs von 
Einbruchsversuchen gegen phpmyadmin auf meinem Server sprechen da eine 
sehr klare Sprache -, der auch mit den raffiniertesten nachgeschobenen 
Hacks niemals eine Struktur bekommen wird, die die ganze Kiste immer 
vorhersehbar reagieren läßt.

Und was ich besonders übel finde: Mit diesem Scheißdreck werden 
Millionen unbedarfter Programmierer regelrecht verdorben, weil sie damit 
nur konditioniert, aber nicht in klar strukturiertem Denken geschult 
werden.

Die PHP-Strategie, die irreparablen Schwächen mit irgendwelchen Flicken 
zu verbrämen, halte ich für grundsätzlich falsch. Der einzig sinnvolle 
Weg wäre ein Versionskonzept, mit dem alte Software weiter betrieben 
werden kann, aber Neuentwicklungen auf ein Konzept geleitet werden, das 
dem Stand der Technik zumindest sehr deutlich näher kommt, als das 
heutige PHP.

Uhu Uhuhu schrieb:
> Ich konnte mir bis vor einigen Tagen, als ich mit gutem Grund damit
> anfing, schlicht nicht vorstellen, daß es möglich ist, eine derartige
> Anhäufung von gröbsten Designfehlern als weidlich genutztes Werkzeug zu
> etablieren.

Doch, das geht ;-)

Die Zahl der Websites, die PHP kritisieren, ist Legion:

Why PHP sucks
http://webonastick.com/php.html

PHP: a fractal of bad design
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

PHP Must Die
http://www.steike.com/code/php-must-die/

Problems with PHP
http://toykeeper.net/soapbox/php_problems/

I’m sorry, but PHP sucks
https://maurus.net/resources/programming-languages/php/

What I don't like about PHP
http://www.bitstorm.org/edwin/en/php/

Experiences of Using PHP in Large Websites
http://www.ukuug.org/events/linux2002/papers/html/php/index.html

und das sind bestimmt nicht alle ;-)

Karl Käfer schrieb:
> liegt zudem nur daran, daß die PHP-Core-Entwickler ihren eigenen
> flex-basierten Parser nicht mehr verstehen.

Richtig flex-basiert ist er auch nicht durchgängig :)

Zahlen werden nicht (ganz) vom Flex gelesen, sondern flex sammelt alle 
chars zusammen, die zu einer Zahl gehören könnten, und dann wird das 
ganz einfach an strtol (o.ä) übergeben.
Ohne Check, ob sich die beiden über die Anzahl der verwerteten Bytes 
einig sind.

Netter Effekt:

1

print 01234567;

2

print 012345678;

geben beide dasselbe aus. Ohne Warnung, ohne Fehlermeldung.

Ich hatte auch noch so eine Merkwürdigkeit:

1

class ... {

2

   const MODULE_PREFIX = 'syntax_variables_";

3

4

   public function handle() {

5

      ...

6

      p_set_metadata($ID, array(MODULE_PREFIX."state" => $data));

7

      ...

8

   }

9

}

Als Tag für $data im Array würde ich syntax_variables_state erwarten.

Tatsächlich stand in den Metadaten von Dokuwiki aber

1

array (

2

   [MODULE_PREFIXstate] => array(...)

3

)

Wenn man

1

   print_r MODULE_PREFIX."state"

ausführt, erhält man syntax_variables_state

Nach solchem Scheißdreck kann man sich einen Wolf suchen...

Kaj schrieb:
> Wie wärs einfach mal mit Doku lesen oder sich mal ein Buch dazu zu
> kaufen?!
> http://www.php.net/manual/de/language.constants.php

Ehe du hier groß das Maul aufreißt, lies selber die Doku: 
http://de3.php.net/manual/de/language.oop5.constants.php

Uhu auch wenn das möglicherweise frustrierend ist muß hier nicht der 
Thread zu einer Schimpftriade ausarten!

Der Verweis war insofern korrekt, als das du (wenn auch unbeabsichtigt) 
solche eine Konstante genutzt hast, und höchstwahrscheinlich sogar eine 
Warnung darüber im log finden wirst (oder in deinem Output falls du das 
nun aktiviert hast) obwohl du eine Klassenkonstante nutzen wolltest.

Daher nochmal von mir der Tipp, das Error Reporting hochzustellen und 
alle Warnungen zu beheben!

Also bitte sachlich bleiben.

Defintiv nur mit error_reporting E_ALL entwickeln!
Das erspart später viel Ärger


Aber das  const MODULE_PREFIX = 'syntax_variables_";
 keine Fehlermeldung liefert verwundert mich gerade doch ein wenig?!

Auch das mit dem parsen der Kommentare war bei mir bisher kein Problem. 
Zumindest bin ich über das Verhalten nie gestolpert.
Es scheint aber tatsächlich so zu sein, dass das "?>" auch in 
Kommentaren geparsed wird
http://www.php.net/manual/en/language.basic-syntax.comments.php

A. B. schrieb:
> Defintiv nur mit error_reporting E_ALL entwickeln!
> Das erspart später viel Ärger

Besser:

error_reporting(-1);

E_ALL ist (Je nach PHP-Version) nicht "Alles", auch wenn der Name das 
suggeriert.

A. B. schrieb:
> Auch das mit dem parsen der Kommentare war bei mir bisher kein Problem.
> Zumindest bin ich über das Verhalten nie gestolpert.

Patternmatching und html-Tags - da rennt man ganz schnell in die Falle, 
wenn man das nicht weiß.


Εrnst B✶ schrieb:
> E_ALL ist (Je nach PHP-Version) nicht "Alles", auch wenn der Name das
> suggeriert.

PHP wäre nicht PHP, wenn es anders wäre...

Phpmyamin scheint für die Hacker wirklich unwiderstehlich zu sein. Ich 
hatte einen Angriffsversuch, der innerhalb von 4 Sekunden 1534 Anfragen 
nach irgend welchen Namen/Pfaden niederprasseln ließ, hinter denen sie 
phpmyadmin erhoffen. Sowas geht schon in Richtung Denial of Service.

ohje...aber das mit dem E_ALL steht ja auch in der Doku :D

Ich denke, man muß PHP mit Humor und bei Bedarf gewürzt mit einer 
ordentlichen Priese Spott nehmen. Einen Verein, an dem 50 Jahre 
Informatik spurlos vorbei gegangen sind, muß man nicht ernst nehmen.

Bleibt also der mehr als ärgerliche Aspekt, daß PHP wohl zu einem 
erheblichen Teil die Grundlage für die Sicherheitprobleme im Web bildet.

dadada schrieb:
> Ich mag auch kein PHP und ja, Serversicherheit ist durch PHP nicht
> optimal. Aber das Problem des Buffer Overflow mitdem auch aus dem Web
> die Computer angegriffem werden ist ein klassischer C designfehler.

Den man vermeiden kann, indem man:
-nicht einfach sofort drauflosschreibt, sondern erst prüft wieviele 
Bytes denn geschrieben werden sollen (in ein Array etc.)
-statische Codeanalyse durchführt
-statt sprintf snprintf verwendet usw.

dadada schrieb:
> Ich mag auch kein PHP und ja, Serversicherheit ist durch PHP nicht
> optimal.

Das ist sehr freundlich ausgedrückt. Ich würde sagen, daß in diesem 
Bereich des Softwareuniversums - man könnte ihn auch Softwarehölle 
nennen - der Begriff "Optimum" noch so weit unter dem Horizont ist, daß 
man darüber weder reden kann, noch muß...

> Aber das Problem des Buffer Overflow mitdem auch aus dem Web
> die Computer angegriffem werden ist ein klassischer C designfehler.

Du weißt, wie alt diese "klassische" Herangehensweise von C ist? Anfang 
der 1970-er Jahre wurde es entwickelt. Und seither wurde C stetig 
weiterentwickelt, um diese alten Schwächen zu entschärfen und die 
Sprache handlicher zu machen. Und dabei hat man sie noch weitgehend 
kompatibel zu älteren Versionen gehalten - deswegen kann man noch heute 
mit den alten Funktionen den alten Mist machen, erhält aber von den 
meisten Compilern eindringliche Warnungen, die nicht in irgend welchen 
Serverlogs verschwinden.

(Diese simplen Funktionen waren übrigens nicht reiner Übermut, sondern 
der Leistungsfähigkeit damaliger Computer geschuldet. Diese Kisten 
liefen z.T. noch im kHz-Bereich der Taktfrequenzen und ein einziges 
Speicherbit kostete einen deutlichen Dollar-Betrag.)

Im Gegensatz dazu PHP: entstanden ist es als Hack, um die mühsame 
HTML-Programmiererei etwas zu erleichtern, gebastelt von Leuten, die von 
Compilerbau keinen blassen Dunst hatten. Seither gab man sich 
hemmungslos der Featuritis ohne Perspektive, Weit- und Überblick hin und 
Macken, die ruchbar wurden, wurden notdürftig mit irgend welchen alten 
Putzlumpen gestopft.


Sprachentwicklung ist halt doch etwas mehr, als ein neues Dutzend 
Funktionen in die Bibliothek reinzuwurschteln, immer ängstlich darauf 
bedacht, den Nutzer nicht durch zu viel Gleichförmigkeit in den 
Interfaces zu langweilen...

Behauptete da nicht jemand, bei PHP gäbe es keinen "Compiler"?

1

Warnung

2

3

Der Großteil der E_STRICT Fehler werden zur Compile-Zeit generiert und

4

werden somit nicht angezeigt, wenn E_STRICT zur Laufzeit zu error_reporting

5

hinzugefügt wird (und auch andersrum).

Quelle: http://php.net/manual/de/function.error-reporting.php

Peter II schrieb:
> Du hast
> behauptet das ein Interpreter Maschinencode erzeugt und das stimmt nun
> mal nicht.

Habe ich nicht. Der Unterschied zwischen einem Comiler und einem 
Interpreter ist im Wesentlichen nur, was mit dem vom Compile-Paß 
erzeugten Code passiert:

Der Compiler konserviert ihn zu späterer, vielfacher Ausführung in einer 
Datei, während ein Interpreter seinen Zwischencode auf einer realen 
Maschine ausführt - also letztlich Befehle für die reale CPU daraus 
macht, die sofort ausgeführt werden.

Die Übergänge sind jedoch fließend: Compiler können alles von einem der 
Quellsprache sehr ähnlichen Zwischencode - z.B. tokenised text -, bis zu 
echtem Maschinencode erzeugen.

Wo man die jeweilige Ausgabesprache ansiedelt, ist meist das Ergebnis 
von Effizienzüberlegungen.

Interpreter können fest mit dem Comiler verbunden sein - so bei PHP - 
oder eine vom Compler getrennt erzeugte Zwischencodedatei einlesen - 
Java, Python.

Bei Java gibt es noch eine Spezialvariante: der Compiler erzeugt einen 
maschinen-unabhängigen Zwischencode, der von einem Compiler-Paß im 
Interpreter - oft sogar "just in time" - in Maschinencode der 
Zielmaschine umgesetzt wird, der sogar zur Wiederverwendung aufgehoben 
werden kann.

Und zuguterletzt ist eine CPU auch nur ein Interpreter in Hardware, der 
aus dem Maschinencode Schaltwerke/Netze zusammenschaltet und so die 
Ausgaben erzeugt, mit denen die ganze Kiste überhaupt erst mit der 
Umwelt in Interaktion treten kann.

Peter II schrieb:
> du hast es immer noch nicht verstanden.
Oh Mann...

> Ein Interpreter macht keinen code.

Er füttert die CPU mit einem Codestrom, der dem Programm entspricht (und 
zusätzlich mit dem Code, den der Interpreter "für sich selbst" braucht). 
Ob der Strom aus einem ROM kommt, oder sonst woher, ist für die Logik 
völlig egal. Interpretation aus Sicht des Interpreters bedeutet, der CPU 
Laufzeitroutinen und Parameter zum Fraß vorzuwerfen - diesen "Fraß" 
könnte man in ein riesiges RAM sequentiell so abspeichern, wie sie vom 
Befehlsdecodierer der CPU gesehen werden - das ist der Codestrom, den 
der Interpreter erzeugt.

> Der Code ist also schon immer vorhanden.

Ja und? Der Code, den ein Compiler erzeugen kann, steht mit Definition 
der Sprache und seiner Implementierung fest und ist - auch wenn die 
Menge riesig, auf einer realen Maschine ist sie endlich - sozusagen auch 
schon vorhanden und ein konkreter Quelltext macht aus dieser Riesenmenge 
nur eine Auswahl. Aus dieser Perspektive ist der Compiler eine 
Suchmaschine, die aus dem (virtuellen) Fundus entsprechend dem Quelltext 
das Richtige raussucht.

Stryker_2k schrieb:
> Ps: Da ich mein Geld mit PHP verdiene sehe ich das ganze aber vielleicht
> auch nicht wie jemand anders. Es ist halt auch nur ein Werkzeug. Hammer
> <=> Schraube

Das ist ja auch richtig so. Aber du hast dich womöglich auch schon über 
einen vermurksten Seitenschneider, oder einen wackligen Hammer geärgert.

Uhu Uhuhu schrieb:
> Aus dieser Perspektive ist der Compiler eine
> Suchmaschine, die aus dem (virtuellen) Fundus entsprechend dem Quelltext
> das Richtige raussucht.

Nachtrag: Das ist das alte Informatikspielchen "Zeit gegen Speicher".

Fakt ist, PHP ist inzwischen so verbreitet, dass es sich noch viele 
Jahre halten wird.
Da gibts wirklich nur die Variante, damit zu leben oder eine andere 
Sprache zu nehmen.

Man muss auch mal die Vorteile sehen; es geht mit PHP schon sehr 
einfach, Daten aus einer Datenbank abzufragen und dann eine HTML-Ausgabe 
zu generieren.

Es gibt auch so etwas wie Compiler für PHP: siehe 
http://en.wikipedia.org/wiki/HipHop_for_PHP zum Beispiel, aber das nur 
am Rande um es noch ein wenig verworrener zu machen ;)

Ich habe länger nichts mehr mit PHP gemacht und Beginne gerade wieder, 
aber was mir da auffält: die Sprache ist ziemlich im Wandel. Vieles was 
vor 3 Jahren ging ist mittlerweile abgekündigt, entfernt oder wird in 
einem der nächsten Releases entfernt

Uhu Uhuhu schrieb:
>> E_ALL ist (Je nach PHP-Version) nicht "Alles", auch wenn der Name das
>> suggeriert.
>
> PHP wäre nicht PHP, wenn es anders wäre...

So wie in C, nämlich -Wall beim gcc...

Stefan Rand schrieb:
> So wie in C, nämlich -Wall beim gcc...

Das ist gcc, nicht C. Für C gibt es viele Compiler, PHP dagegen ist 
einmalig und es findet sich auch garantiert keiner, nichtmal ein 
Verrückter, der dieses Chaos nachimplementiert...

Michael Krauth schrieb:
> Vielleicht bin ich doof, aber

und was ist so schwer daran zu kapieren, das PHP kein perfektes PHP 
formatiertes File sondern ein eher recht als schlecht zusammengehacktes 
HTML bekommt und dort alles was zwischen <?php ?> steht, ungeachtet von 
Zeilenumbrüchen etc verarbeiten muss/soll/darf/....

Es ist halt so. In nahezu jeder Programiersprache ist es nicht möglich 
innerhalb eines Block-Kommentars das Kommentarendezeichen zu verwenden, 
trotzdem stört sich da niemand sondern empfindet das als "normal".

Es ist doch müßig sich über solche Sachen zu echauffieren, die Lösung 
liegt doch auf der Hand:
a) Alternative Sprache nutzen die "besser" ist
b) sich sein eigenes PHP kompilieren was diesen "Bug" nicht hat

Karl Käfer schrieb:
> einfach eine Datei mit der entsprechenden Dateinamenerweiterung
> hochladen, schon läuft

Quatsch, auch das muss aktiv sein, ebenso wie man den Server 
konfigurieren muss ein oder alle Verzeichnisse für CGI zuzulassen. Der 
Unterschied ist nur, das CGI muss für den Server passend kompiliert 
werden, PHP kann ich "einfach" überall laufen lassen wo PHP zur 
Verfügung steht.

Karl Käfer schrieb:
> eine Art "erweitertes SSI" angesehen

ist es doch auch, PHP ist im prinzip nur interpretiertes HTML und ganz 
stark daran ausgerichtet, was halt nicht unbedingt zum Vorteil von PHP 
gereicht.

Uhu Uhuhu schrieb:
> PHP dagegen ist einmalig

Phalanger. HipHop.

Läubi .. schrieb:
> Es ist halt so. In nahezu jeder Programiersprache ist es nicht möglich
> innerhalb eines Block-Kommentars das Kommentarendezeichen zu verwenden,
> trotzdem stört sich da niemand sondern empfindet das als "normal".

Nicht alles, was hinkt, ist ein Vergleich. ?> ist kein 
Kommentarendezeichen. Auch in PHP nicht.

Uhu Uhuhu schrieb:
> Nicht alles, was hinkt, ist ein Vergleich. ?> ist kein
> Kommentarendezeichen. Auch in PHP nicht.

Doch, im Prinzip schon. Es ist das Zeichen, welches den PHP von dem 
"HTML-Mode" in der "Interpreter-Mode" schaltet, ebenso wie ein Compiler 
vom "Parser-Mode" in den "Kommentar-Mode" schaltet.
Auch wenn ich langsam denke du willst das garnicht verstehen sondern 
einfach nur deinen Frust loswerden, PHP hat nicht als Input ein "plain 
php skript" sondern ein Textfile (idr. HTML) welches keine, eine oder 
mehrere <?php ?> (und in bestimmten Modi sogar <% %> und <? ?>) 
enthalten kann.
Außerhalb wird alles 1:1 durchgereicht und innerhalb halt als PHP 
interpretiert, um um dieses inlining zu unterstützen wird halt auch kein 
extra Umbruch eingefügt, und auch nicht Umbrüche benötigt.

Das das jetzt in ganz speziellen Sonderfällen zu Problemen führt ist 
halt so und lässt sich aber (s.o.) relativ einfach umgehen indem man 
diese Steuerzeichenfolge "aufbricht".

Läubi .. schrieb:
> Doch, im Prinzip schon. Es ist das Zeichen, welches den PHP von dem
> "HTML-Mode" in der "Interpreter-Mode" schaltet, ebenso wie ein Compiler
> vom "Parser-Mode" in den "Kommentar-Mode" schaltet.

Daß es das tut, ist offensichtlich. Daß das Ganze ein kapitaler 
Design-Fehler ist, aber auch...

> Auch wenn ich langsam denke du willst das garnicht verstehen sondern
> einfach nur deinen Frust loswerden

Frust? Nein, ich amüsiere mich darüber nur noch. Dazu muß man sich 
wirklich nicht in den geistigen Morast derer begeben, die diesen Unsinn 
verbrochen haben. Es reicht, die gröbsten Schoten zu kennen, um relativ 
schnell auf die Idee zu kommen, daß bei dieser Sprache sowieso alles 
anders ist, als man denket.

Ohne Sinn und Verstand irgendwas zusammenzuwursteln ist keine Kunst und 
gutes Design¹ zeichnet sich dadurch aus, daß es den für den Anwender 
notwendigen Regelsatz klein und konsistent hält. Das Auswendiglernen von 
Konvoluten von Qualität und Umfang eines Großstadt-Telefonbuchs ist 
ziemlich ineffizient und lenkt vor allem von dem ab, was man eigentlich 
vor hat.

-----------------

¹) Yukihiro Matsumoto hat mal irgendwo sehr schön beschrieben, dass es 
ihm sehr wichtig ist, Ruby möglichst intuitiv zu gestalten. Dazu wird 
experimentiert und vor allem viel nachgedacht. Im Suff mal eben wieder 3 
Dutzend "Neuerungen" über über der werten Anwenderschaft auszukippen, 
geht einfach nicht...

Wie gesagt, PHP kann man verwenden, muss man aber nicht.

Mark Brandis schrieb:
> Wie gesagt, PHP kann man verwenden, muss man aber nicht.

Du irrst. Wenn man für Dokuwiki Plugins schreiben will, hat man kaum 
eine andere Wahl...

Uhu Uhuhu schrieb:
> Wenn man für Dokuwiki Plugins schreiben will, hat man kaum
> eine andere Wahl...

Ja nun, auch zu Dokuwiki gibt es Alternativen.

Wenn es beruflich ist und vom Arbeitgeber so vorgegeben dass PHP benutzt 
werden muss, nun gut. Dann macht man es halt.

Mark Brandis schrieb:
> Ja nun, auch zu Dokuwiki gibt es Alternativen.

Wenn man jeden Morgen aufs neue vor dem Nichts steht, mag das stimmen...

gaast schrieb:
> In dem Moment, wo PHP die HTML-Datei nach den Tags <? und ?> durchsucht,
> wird noch kein PHP geparst, ganz einfach.

Du must nich versuchen, den Mist zu entschuldigen. Der ist 
unentschuldbar...

gaast schrieb:
> weil das wiederum andere Seiteneffekte haben könnte.

Tja, das hätte man sich als allererstes überlegen müssen, als PHP 
konzipiert wurde...

Da aber nichts konzipiert wurde, sondern einfauch drauflos gefrickelt, 
konnte halt nicht viel Gescheites dabei rauskommen. Daß der Frickler von 
Compilerbau nicht den Schimmer von einer Ahnung hatte, ist 
Voraussetzung.

gaast schrieb:
> Hatte ich auch nicht. Von dir verlangt ja auch keiner, dass du dich
> dafür entschuldigst, dass du nicht begreifst dass der Parser in dem
> Moment, in dem er HTML durchsucht, noch gar kein PHP parst, weil das
> wiederum andere Seiteneffekte haben könnte.

Mag ja sein.
Allerdings ist die Bezeichnung 'Parser' etwas sehr hoch gegriffen, wenn 
er in

1

// $this->Lexer->addSpecialPattern('<smallcaps.*?>', $mode, 'plugin_smallcaps_syntax');

ein in einem String stehendes ?> als sein Ende Zeichen erkennt, das zu 
allem Überfluss auch noch auskommentiert ist.
'Parser' würde ich sowas nun wirklich nicht nennen wollen. Murx schon 
eher.

Nun fang du auch noch an! :-P
Der PHP "Parser" kommt doch zu dem Zeitpunkt noch überhaupt nicht ins 
Spiel! Es gibt da auch noch keine Kommentare... Das ganze wird 
vermutlich einfach als Stream gelesen und wenn das "php-anfang" Zeichen 
kommt dem Parser gereicht und beim "phph-ende" Zeichen beendet... 
Fertig.

Das ist nurn wirklich ein dermaßen seltener Spezialfall, das die meisten 
PHP Entwickler nie in ihrem Leben nur in die Verlegenheit kommen das 
wissen zu müssen.
Und selbst wenn werden diese dann wohl einfach den Workaround dafür 
nutzen anstatt da nun tagelang drüber zu lamentieren und sich 
aufzuspielen man selber hätte das ja alles viel besser gemacht.

Nachtrag: Um mal zu seigen was man alles "böses" mit PHP machen kann:
http://www.onlamp.com/pub/a/php/2001/05/03/php_foundations.html
besonders der letzte teil mit den gesplitteten if/for Bedingungen 
innerhalb eines HTML Dokumentes! Praktisch kann das alles sein, XML, 
Text, CSS, theoretisch würde vermutlich sogar eingeschränkt Binärdaten 
funktionieren.

Man muss sich einfach mal davon verabschieden, das PHP "nur" PHP Skript 
zu Gesicht bekommt.

Läubi .. schrieb:
> Nun fang du auch noch an! :-P

:-)
Ich wusste von all dem nichts.
Aber als ich die weiter oben verlinkten 'Warum PHP Murks ist' Seiten 
angefangen habe zu lesen, da sind mir ehrlich die Grausbirnen 
aufgestiegen. Den letzten Rest gaben mir dann noch einige Zitat, die ich 
vom Erfinder von PHP gelesen habe. Der könnte sich nahtlos in so manche 
Arduino Fraktion hier einreihen (Tschuldigung, das soll kein neues 
Arduino-Bashing werden)

> Der PHP "Parser" kommt doch zu dem Zeitpunkt noch überhaupt nicht ins
> Spiel! Es gibt da auch noch keine Kommentare... Das ganze wird
> vermutlich einfach als Stream gelesen und wenn das "php-anfang" Zeichen
> kommt dem Parser gereicht und beim "phph-ende" Zeichen beendet...
> Fertig.

So wirds wahrscheinlich sein. Aber selbst der C-Präprozessor, der nun 
wirklich nicht so wahnsinnig viel von C versteht, ist immerhin soweit, 
dass er aus Strings die Nase raushält.
Auf jeden Fall hab ich jetzt gute Argumente, wenn ich in die nächste 
"PHP ist super, C ist Scheisse" Konfrontation gehe. :-)

Karl Heinz schrieb:
> "PHP ist super, C ist Scheisse"

Was soll das den sein? Jedes Werkzeug für seinen Zweck. PHP und C haben 
nun doch ganz andere Einsatzgebiete...

Läubi .. schrieb:
> Jedes Werkzeug für seinen Zweck.

Ja, PHP zur Produktion von Schwachstellen im Internet, damit Mafia und 
ihr legal-schattiger Arm immer genug Gelegenheiten finden, "ihren Job zu 
machen"...

Naja, also "dos and donts" gibt es in jeder Programmiersprache.

Auch in C kann ich z.B. mit goto rumfuhrwerken, wobei man auch in jedem 
Programmierlehrbuch liest, das man dies tunlichst lassen soll.
Und hier mit Beispielen von 2001 anzukommen ist da auch nicht wirklich 
fair.
Heute würde sowas niemand mehr machen, da man versucht Code und HTML zu 
trennen indem man Template Systeme verwendet.

Jedem Neuling hier wird in den Arsch geblasen er solle doch gefälligst 
ein C Buch lesen. Das gleiche könnte man für PHP ja auch empfehlen. 
Sicher gibts bei PHP viel Murks, was ich auch überhaupt nicht schönreden 
will, aber das sich hier nun jeder als PHP Crack empfindet nur weil er 
zwei Links zu PHP überflogen hat, finde ich schon etwas sehr 
überheblich.

Der grosse Vorteil der geringen Einstiegshürde von PHP ist gleichzeitig 
auch der grösste Nachteil, da jeder 08/15 Mist zusammenhacken und online 
stellen kann. Mit C Pufferüberläufe, Crashs und sonstigen Scheiss zu 
produzieren ist auch überhaupt kein Problem, nur bekommt davon der Rest 
der Welt eben nix mit.

So, jetzt kommt die Stunde der PHP-Cracks:

Warum schmeißt PHP den Löffel, wenn es diese Zeile siht:

1

$this->Lexer->addSpecialPattern('<smallcaps.*?>', $mode, 'plugin_smallcaps_syntax');

aber nicht, wenn es diese sieht:

1

$this->Lexer->addEntryPattern('<variables.*?>(?=.*?</variables>)', $mode, 'plugin_variables_syntax');

Kaj schrieb:
> Sagst du uns auch noch welche PHP-Version?

5.3

http://xref.dokuwiki.org/reference/dokuwiki/nav.html?_functions/addspecialpattern.html

"Perl style regex. Must be UTF-8 encoded. ..."
Dann kodiere deine SearchPatterns doch mal entsprechend. Steht alles in 
der Doku ;)

Und was bedeutet "gibt den Löffel ab"? Fehlermeldung? Errorlogs?



Und gewöhn dich einfach daran, das "?>" ne spezielle Bedeutung hat und 
verschwende nicht deine Zeit mit irgendwelchen Patterns die nun den 
"Grenzbereich" ausloten.
Genausogut kannst du "?" mit "{0,1}" ersetzen und hast das problem nicht 
mehr. Aber das wäre wahrscheinlich zu einfach und zu langweilig und man 
könnte sich nicht über das beschissene PHP aufregen

siehe auch:
http://stackoverflow.com/questions/15219815/convert-php-closing-tag-into-comment

A. B. schrieb:
> "Perl style regex. Must be UTF-8 encoded. ..."

Sind sie. Zudem ist die Codierung von '<smallcaps.*?>' in ansi und UTF-8 
gleich.

> Und was bedeutet "gibt den Löffel ab"?

PHP beendet einfach die Bearbeitung der Seite, wenn es ?> sieht - egal, 
ob in einem String, oder gar einem auskommentiertzen String, oder 
sonstwo. Aber offenbar auch nicht immer.

Die stackoverflow-Seite ist lustig - zu jedem Hack den passenden 
Gegenhack und die Welt ist wieder in Ordnung...

Was passiert wenn du

1

$this->Lexer->addSpecialPattern("<smallcaps.*?>", $mode, "plugin_smallcaps_syntax");

verwendest? Ändert das etwas?

"PHP only honours the ?> tag outside a string context. Putting it in a 
string just works as expected. In other words, you cannot break out of 
PHP mode from inside a string literal."

PHP unterscheidet ja zwischen single und double quoted und nur double 
quoted sind "richtige" Strings.

A. B. schrieb:
> Ändert das etwas?

Nichts - alles schon ausprobiert.

> PHP unterscheidet ja zwischen single und double quoted und nur double
> quoted sind "richtige" Strings.

Strings in "" werden interpoliert, Strings in '' nicht - wie in der 
Shell, und bei ruby. Von "richtigen" und "nicht richtigen" Strings würde 
ich da nicht sprechen. Beide haben ihre Berechtigung und die '' sind 
sicherlich etwas effizienter zu behandeln, weil sie nicht durchsucht 
werden müssen.

Uhu Uhuhu schrieb:
> Ja, PHP zur Produktion von Schwachstellen im Internet, damit Mafia und
> ihr legal-schattiger Arm immer genug Gelegenheiten finden, "ihren Job zu
> machen"...

Uhu das ist doch Quatsch... Ja es gibt unsichere Skripte. Genauso wie es 
Million und abermillionen unsicher anderer Software gibt, da kann aber 
die Verwendete Sprache nix für.

Und ja es gibt/gab einige besonders Problematische Funktionen und 
Configparameter, wie es z.B. auch im C Standard problematische 
Funktionen gibt die heute nicht mehr empfohlen werden zu nutzen.

Das es häufiger Exploits für bekannte PHP Skripte gibt, liegt einfach an 
der Verbreitung und dem Erfolg.

Und wie gesagt, niemand hält dich davon ab dir ein "besseres" PHP zu 
kompilieren, du müsstest dann halt nur die nicht mehr gewährleistete 
Rückwärtzkompatibilität ggf. in den von dir verwendeten Skripten halt 
kurz ausgleichen. Für einen derart versierten Entwickler der sich anmaßt 
die Arbeit und de Erfolg anderer derart herabzuwürdigen sollte das ja 
kein Problem sein.

Läubi .. schrieb:
> Für einen derart versierten Entwickler der sich anmaßt die Arbeit und de
> Erfolg anderer derart herabzuwürdigen sollte das ja kein Problem sein.

Au Mann... Es geht mir nicht darum, irgendwelche "Erfolge" 
herabzuwürdigen. Es gibt längst Besseres, um PHP zu ersetzen, das schon 
bei seiner "Entwicklung" Lichtjahre hinter dem Stand der Technik 
herwatschelte, ohne ihn auch nur zur Kenntnis genommen zu haben.

Der Teufel scheißt bekanntlich immer auf den größten Haufen und Naivität 
und Trägheit läßt es ihm die Leute nachmachen.

Aber wer sagt, daß der Kaiser nackt da steht, ist natürlich böse, wie 
immer...

Phyton gabs z.B. schon früher als PHP. Ruby ist zu einem ähnlichen 
Zeitpunkt wie PHP entwickelt wurden.
Wieso haben die sich dann nicht durchgesetzt wenn sie so viel besser 
sind?
Das sind jetzt mal die einzigen beiden Alternativen die mir da fürs Web 
einfallen auf die schnelle. Java ist mit deutlich mehr Aufwand 
verbunden.

Oder was kommt dir als Alternative in den Sinn?

Fred schrieb:
> Ruby ist ja bis heute noch extrem japanisch durchsetzt. Ja, die
> Haupt-Entwickler haben mittlerweile zugesagt, sich um englische
> Kommunikation zu bemühen.

Ich habe vor ein paar Jahren ein Projekt mit Rails gemacht. Über 
Probleme mit Japanischen Texten kann ich mich nicht beklagen; die ganze 
Dokumentation liegt in Englisch vor.

A. B. schrieb:
> Oder was kommt dir als Alternative in den Sinn?

Python. Rails hat einen zu komplizierten Ansatz mit seinen vielen 
Automatismen, kann aber auf der anderen Seite die Produktivität bei 
anspruchsvolleren Projekten gehörig steigern.

Mich schrecken bei Python die fehlenden Klammern ab. Ich finde das 
hochgradig beschissen, darüber mein Programm strukturieren zu müssen.
Wie funktioniert das so im Programmieralltag? Oder ist das im Endeffekt 
gar kein so grosses Ding, wie es mir erscheint?

Ich mag es auch nicht sonderlich, aber es man kann sich durchaus daran 
gewöhnen.

Vorteil von Python ist seine Mächtigkeit und Effizienz.

A. B. schrieb:
> Mich schrecken bei Python die fehlenden Klammern ab. Ich finde das
> hochgradig beschissen, darüber mein Programm strukturieren zu müssen.

Du meinst über die Einrückung zu Beginn einer Programmzeile? Ja, das 
nervt echt kolossal an Python. So toll die Sprache ansonsten auch sein 
mag, aber das halte ich IMHO für einen Designfehler.

Fred schrieb:
> Die Ruby-Entwicklung fand ausschließlich auf japanischsprachigen MLs
> statt.

Und was ist daran jetzt schlecht?

Ach, so einer bist du...

xD

Kaj schrieb:
> Das ist doch blödsinn. Ich weiß ja nicht wie ihr so Programmiert, aber
> ich rücke meinen Code eh immer ein (C/C++, PHP, .NET oder was auch
> immer). Also, wo sollte da jetzt das Problem sein? Ob der Code nun
> zwischen klammern steht und dann eingerückt wird, oder ohne Klammern
> eingerückt wird...

Natürlich rückt man seinen Code ein. Aber der Grund dafür ist die 
Lesbarkeit für den Menschen, und eben nicht dass man damit etwas über 
den Kontrollfluss aussagen will. Da hat der Guido van Rossum etwas 
missverstanden. ;-)

Außerdem gibt es für C, C++, Java, JavaScript, C# und viele andere 
Sprachen auch Beautifier-Tools, die das Einrücken automatisch richtig 
machen. Bitte zeig mir so ein Tool für Python. :-)

Wie ich gerade sehe, hat man dies von Python 2 auf Python 3 verbessert 
(man kann nicht mehr Spaces und Tabs mischen), was nichts anderes 
bedeutet als dass es in Python 2 schrottig war. ;-)

http://regebro.wordpress.com/2008/05/30/python-indendation-rocks-and-sucks-a-little-bit/

Mark Brandis schrieb:
> Bitte zeig mir so ein Tool für Python. :-)

Braucht man ja auch nicht ;-)

A. B. schrieb:
> Auch in C kann ich z.B. mit goto rumfuhrwerken, wobei man auch in jedem
> Programmierlehrbuch liest, das man dies tunlichst lassen soll.

Das ist zu kurz gedacht. Ein "guter" Anwendungsfall ist das Abbrechen 
eines verschachtelten Schleifenkonstruktes mit einem Sprung hinter die 
äußere Schleife.

Man könnte das natürlich auch dadurch dadurch lösen, daß man die 
Schleifen in eine Funktion verpackt und mit return verläßt, wenn man 
ein break ganz raus haben will. Ob das aber immer der Übersichtlichkeit 
dient, möchte ich bezweifeln.

Eine nette Lösung für das Problem, mit der sich kein Schindluder wie mit 
goto treiben läßt, hatte Burroughs in seiner Sprache SDL, in der v.a 
Betriebssysteme geschrieben wurden:

1

do outerloop forever

2

   do forever

3

      do forever

4

         ...

5

         undo outerloop

6

         ...

7

      end

8

      ...

9

    end

10

end

outerloop ist der (frei wählbare) Name der Schleife, die durch undo 
beendet wird und forever heißt, daß es sich um eine Schleife ohne 
Endekriterium im Schleifenkonstrukt handelt - entspricht while(true) in 
C.

goto gab es nicht und do ... end war ein einfacher Block, wie { } in C.