IO bzw. CGI.pm Upload speichern

[Alexander (HH)]

Moin Moin!

Nun, da wir die Home-Verzeichnisse von nobody und www kennen, sag mir doch bitte mal, wie der absolute Pfad von "'tmp' in its home directory" ist.

Der "current user" soll weder www noch nobody noch www-data sein. Es tummeln sich mehrere Leute auf dem Server und ich halte es auch generell nicht für ne gute Idee Dateizugriffe mit nem Defaultuser zu machen. Und dem spendiere ich doch sehr gerne ein home-dir.

Der Punkt ist, dass CGI.pm nicht gezielt für Dich entwickelt wurde, sondern für Leute, die *irgendwo* ein CGI laufen lassen wollen.

Man sollte also das Home des Users auf der gleichen Platte wie die Uploads haben.

Falsch. Man sollte nicht davon ausgehen, dass die Temp-Dateien an irgendeiner nützlichen Stelle liegen.

Das Tmp-dir wird wohl kaum im Wochenrhythmus umziehen, m.a.W. testen solte man sein CGI zumindest einmal schon. (ich schreibe kein Modul sonderne eine Anwendung...)

Und Module testest Du nicht? Oder wie soll ich das verstehen?

Wie gesagt: Das CGI-Modul geht davon aus, dass jeder Server etwas anders ist. Es hat außer Perl 5.x und einem Webserver mit CGI-Schnittstelle sehr wenige Voraussetzungen, und es macht über sehr wenige Dinge konkrete Annahmen. Deswegen funktioniert es in so ziemlich jeder CGI-Umgebung mit Perl-Interpreter. Das dürfte einer der Gründe für die weite Vebreitung des CGI-Moduls sein. Wenn Deine Anwendung mehr Dinge voraussetzt, hindert Dich niemand, bestimmte Annahmen zu machen. Das bedeutet aber auch, dass Deine Anwendung nicht überall da laufen wird, wo auch das CGI-Modul funktioniert.

Wenn Du Dich auf bestimmte Einschränkungen einläßt, kannst Du auch das Verhalten des CGI-Moduls ändern. Entweder, indem Du eine Kopie des CGI-Moduls an Deine Bedürfnisse anpaßt und dafür sorgst, dass *Dein* CGI-Modul vor dem Standard-Modul gefunden wird, oder indem Du vom CGI-Modul erbst und die Anpassungen durch Vererbung vornimmst. Oder Du änderst das Verhalten des CGI-Moduls zur Laufzeit, in dem Du bestehende Funktionen und Methoden gegen eigene austauschst. Ich habe alle drei Varianten durchgespielt, die letztere ist recht erfolgreich, um den UTF-8-Support deutlich zu verbessern. Per Vererbung oder Laufzeit-Patch lassen sich einige Dinge (z.B. XHTML-Bevorzugung) leider nicht komplett ändern, so dass ich letztlich doch eine gepatchte Kopie weit vorne in @INC platziert habe.

link() funktioniert nur innerhalb eines Dateisystems, und längst nicht auf jeder Plattform.

das Missverständnis war absehbar, nennen wir es also move() analog zum shell-mv wird entweder ein rename gemacht oder auf ne andere Platte kopiert.

Das läßt sich leicht in einen Wrapper packen. Wenn Du das CGI-Modul nicht anfassen willst, wirst Du um einen Wrapper kaum herumkommen.

Ich habe in den letzen Monaten mehrmals überlegt, das CGI-Modul von Grund auf neu zu schreiben, mit annähernd gleicher Schnittstelle zum Script, aber mit mehr Ordnung und Struktur hinter den Kulissen.

VIEL ERFOLG! :)

...mir sind auch schon Bugs aufgefallen!

http://search.cpan.org/~lds/CGI.pm-3.29/CGI.pm#BUGS

es wird gemunkelt Perl6 käme 2008 raus, in dem Umfeld könntest du mit einem CGI::Reloaded oder CGI::Revolutions bestimmt punkten.

Perl6 kommt, wenn es fertig ist. Und bis es zu relvanten Hostern durchschlägt, wird es seeeeeehr lange dauern. Es gibt immer noch Hoster mit Perl 5.005. Ich bezweifle sehr, dass sich die Leute nach dem Release von Perl 6 sofort darauf stürzen und feierlich ihre Perl-5-Bücher verbrennen. Perl 6 ist so drastisch anders, dass es im Idealfall eine sanfte Migration geben wird. Im schlimmsten Fall wird Perl6 der größte Flop aller Zeiten.

Alexander