|
|
 |

|

 |

| Community » CGI: Allgemeines Forum |
|
CGI::Appli., HTML::Templ., Image::Size not implemented? Try this!
|
Seitenanfang |
Hallo perlUnity, habe ein Modul selbst geschrieben mit o.g. Modulen. Laeuft gut auf eigenem Linux mit selbst konfiguriertem Apache(localhost). Bei ISP's voelliges Versagen.Wuerde mir Erfahrungsaustausch wuenschen, der dieses Problem mal kompakt anspricht. Deswegen auch das "Try it". Wenn ich mit euerer Hilfe diese Applikation installieren koennte, soll fuer die Unity daraus ein solcher Artikel werden. Fuer perldoc scheint mein Englisch zu schlecht. Beispiele bringen es dagegen sehr, wenns die richtigen sind. Massnahmen: 1) Fand lediglich den "Stein"-Tipp use lib ".", was (in der Not) bedeutet: Leg dein Modul ins Verz. des App-Skriptes und es wird gelesen werden. Geht auch. Was aber wenn o.g. Module vom ISP nicht eingebunden wurden? 2) Auf der lokalen Konfiguration kann Apache ein index.cgi lesen und ausfuehren. Was, wenn der ISP dies nicht unterstuetzt? Index.html benutzen und darin cgi skript aufrufen? Was denken die Experten darueber, dass ich plante, alles mit xyz.pm/eigenentwicklung plus runscript.cgi zu machen. Ich hoffe Gutes, denn eigtl. bin ich mit der Loesung zufrieden, wenn nur nicht die weltlichen ISP-Probleme vorlaegen. 3) So viele reden von Perl CGI und und . Sind ja auch SuperModule :-) Nur habe ich in Wochen nichts gefunden, was auf die Realo-Probleme eingeht. Erster Hinweis hier im Forum (2,3 Jahre alt). Grüße benn
Datum: 05.01.2005-11:29

|
re: CGI::Appli., HTML::Templ., Image::Size not implemented? Try t
|
Seitenanfang |
| Zu 1) Ja, die meisten haben bei Miet-Webspace nur das Standard-Perl + ein paar der gebraeuchlicheren Module zur Verfuegung. Schliesslich wollen die Provider auch noch ein paar Root-Server vermieten :-) use lib '.'; hilft auch nur bedingt. Wenn man keinen Shell-Zugriff hat um das Modul wenn noetig zu kompilieren und benoetigte Libraries zu installieren, ist Ende. Zu 2) Wo ist das Problem? Wenn index.cgi nicht geht, benennt man das Skript um in index.pl. Deswegen im Skript auch besser $ENV{SCRIPT_NAME} benutzen und nicht eine selbst festgelegte Variable mit der Skript-URL. Die Aufteilung in Skript und Module hat noch nicht viel zu sagen. Es kommt primaer darauf an wie die Module geschrieben wurden. Zu 3) In fast jeder Modul-Installationsanleitung (README) steht drin wie man den Installationsort mit weiteren Parametern (meist prefix, LIB, oder aehnliches) festlegen kann, wenn nicht in die @INC-Verzeichnisse installiert werden kann.
Datum: 05.01.2005-14:32

|
re: CGI::Appli., HTML::Templ., Image::Size not implemented? Try t
|
Seitenanfang |
| Lesetipp zum Thema Installation von Modulen auf Webservern: http://board.perl-community.de/cgi-bin/ikonboard/ikonboard.cgi?act=ST;f=4;t=81
Datum: 05.01.2005-15:18

|
re: CGI::Appli., HTML::Templ., Image::Size not implemented? Try t
|
Seitenanfang |
Dank fuer die prompten Reaktionen. Welcher ISP laesst einen Zugriff zu, durch den ich fehlende Module wie CGI::Application kompilieren koennte? Stuende dieses kompilierte Modul dann auch allen anderen Website-Kreatoren zur Verfuegung oder dann nur mir? Weil ich es sozusagen lokal in "meinem" Path kompilierte? (DAS wär die Lösung all meiner Probleme :-))Root-Server -- hab ich so noch nicht gehoert, sorry, ich lerne noch. Heisst das, dass ich muehelos fehlende Module ueber Telnet (noch nie gemacht) oder so installieren koennte? Kann ich mir nicht vorstellen, dass ein ISP so was zulaesst, daher hier die Frage. Oder ist das eine Kostenfrage? *.pl oder *.cgi. Wenn der server index.cgi nicht lesen will/darf, dann wohl auch kaum *.pl oder? Hab es in meinem Frust noch nicht ausprobiert. Richtig ist doch wohl, dass der webmaster seinem Server dies erlauben muss (httpd.conf)? Ich will auch nicht die Site mit www..../index.html oder pl oder cgi aufrufen. Index.html wird ja auch blind erkannt. Wie kann man einen ISP zu sowas bewegen? Ich werd jetz noch mal die READMEs lesen, aber wie schon angedeutet, oft helfen die Docs nicht, weil man gewisse engl. Sentenzen nicht versteht und evtl. dabei das Beste noch ueberliest, da Zeitmangel etc.
Datum: 05.01.2005-21:02

|
re: CGI::Appli., HTML::Templ., Image::Size not implemented? Try t
|
Seitenanfang |
| Zeitmangel beim Lesen von Doku? Das gibt's nicht. Da nimmt man sich einfach die Zeit, weil alles andere was folgt dann einfach besser und schneller geht... Zu deinen Fragen: Welcher ISP Shell-Zugriff zulaesst findest Du am ehesten hier: http://www.webhostlist.de/host/data/webhosting_suche.php?ref=vollsuche.php3 Da kannst Du gezielt nach Features suchen, die Du haben willst. Und wenn moeglich solltest Du SSH und SCopy statt Telnet und FTP nehmen, denn dann rauscht dein Passwort auch nicht unverschluesselt durch's Netz. Wenn Du das Modul z.B. in dein Home installierst, dann hazst natuerlich auch nur Du Zugriff darauf. Wenn jeder User das Home-Verzeichnis der anderen User auslesen kann, wuerde ich schnellstens den Provider wechseln. Root-Server heisst einfach nur, das Du den gesammten Server (also die Hardware auf dem das ganze laeuft) fuer dich alleine hast und nicht mit anderen Domains teilen musst. Und Root-Server auch weil man darauf im allgemeinen Root-Rechte hat und sich die Kiste konfigurieren kann wie man will. pl vs. cgi: Der Server kann (unter anderem) anhand der Dateiendung konfiguriert werden, was er als CGI ausfuehrt und was nicht. Meistens ist da eben nur pl eingerichtet. >> Wie kann man einen ISP zu sowas bewegen? Meistens gar nicht. Man bekommt das was man gekauft/gemietet hat. Man muss eben vorher die Webspace-Paket-Beschreibung lesen und dann schauen was man braucht. Manchmal kann man das ganze ueber die .htaccess beeinflussen/aendern/erweitern, sofern der Provider das nicht in der Conf abgeschaltet hat.
Datum: 06.01.2005-00:22

|
re: CGI::Appli., HTML::Templ., Image::Size not implemented? Try t
|
Seitenanfang |
Vielen Dank fuer den webhosting Link. Ebenso fuer den Root-Server-Hinweis. Werde die Angebote mal pruefen.So long
Datum: 06.01.2005-08:59

|
|

|

|

|
 |

|

|
|