also, da die frage öfter auftaucht, habe ich mich mal hingesetzt und was gebastelt.
problemstellung: man hat einen server mit perl und möchte ein cpan-modul
installieren, das vielleicht auch noch einen C-anteil hat.
man hat keinen shell-zugriff, aber man kann über system() make
aufrufen.
mit folgendem skript sollte das gehn: (http://www.tinita.de/projects/perl/modules/cgipan_cgi.txt)
Update: http://sourceforge.net/projects/cgipan/

installation: ins cgi-bin legen und es sollte lauffähig sein. rechte setzen
natürlich!
dann passt man die variablen $self, $make, $tar, $build_dir, $lib
an.
$lib ist das verzeichnis, in das die module installiert werden sollen.
$build_dir ist das verzeichnis, in das die packages reinkommen (also
die Modul-3.14.tar.gz dateien) und entpackt werden. beide
verzeichnisse müssen für den webserver-user schreibbar sein,
falls das nicht so ist oder die verzeichnisse fehlen, zeigt das skript
die passende fehlermeldung.
$tar und $make sind die pfade zu den tools tar und make. die
default-einstellung sollte auf den meisten servern passen.
$self ist die url zum skript.
wenn alles angepasst ist und keine fehlermeldungen erscheinen, legt man
Modul-3.14.tar.gz ins $build_dir und ruft nochmal das skript auf. nun sollte
das tar-file erscheinen, und man kann nun "unpack" aufrufen und
die weiteren schritte machen.

vorsicht: das skript sollte nicht öffentlich zugänglich sein!

es ist bisher nur von mir getestet, deshalb würde ich mich freuen,
wenn es jemand mal bei sich ausprobieren könnte.

leider ist es bisher nur in englisch.

edit: url geändert.\n\n

<!--EDIT|pq|1108831089-->

$self kann man dem User doch durch FindBin abnehmen, oder ist das kein Standard-Modul?
Anonsten freut es mich zu sehen, dass es sowas (endlich?) gibt.
mfg pktm\n\n

<!--EDIT|Strat|1104355355-->

cool; danke;
werde es demnächst mal testen

stimmt, $self könnte man auch durch $ENV{SCRIPT_NAME}
ersetzen. hab ich jetzt mal gemacht. danke.
ich versuche hier weitgehend auf module zu verzichten, da auf meinem server
z.B. CPAN.pm fehlt. und das ist normalerweise auch standard.\n\n

<!--EDIT|pq|1104351231-->

Oh toll :-)
Das werd ich bei Gelegenheit auch mal ausprobieren.

Schließlich hab ich jetzt seit neuestem auch die Möglichkeit, Perl-CGI-Skripte bei meinem Provider laufen zu lassen. Allerdings haben erste Versuch noch nicht funktioniert. (Das Skript des Providers funktioniert, eigene Hallo-Welt-Skripte "funktionieren nicht" ... wenn ich dazu Eure Hilfe will, beschreib ich das woanders genauer, muss mich erstmal selbst bei Gelegenheit genauer damit auseinander setzen.)

Aber wenn es geht werd ich bestimmt gern auf dieses Hilfsmittel zurückkommen.

@Crian: Lesenswert: http://wiki.perl-community.de/bin/view/Wissensbasis/FaqCGI ;)

random thoughts:

- es bietet mir an, pl-dateien auszupacken.
- viel spass bei der manuellen verfolgung der abhängigkeiten.
- bei fehlern im testlauf werden die zeilen arg lang.
- fehler/warnungen mit farbe versehen?( s.u. )
- im dist modus prüfen, ob das modul in der version schon vorhanden ist?

sub makefile:
$out =~ s/(Warning.*?\n)/<span style="color:orange;">$1<\/span>/g;

sub make_test
$out =~ s/(Can't locate (.*?) in \@INC)/<span style="color:red;">$1<\/span>/g;

Hab mir mal das Script angeschaut und ein paar Anregungen dazu:

Die Variablen die anzupassen sind, koennte man doch auch ueber die CGI-Formulare einstellen.
Im ersten Schritt erraet das Script durch ein paar Test wie die Variablen zu setzen sind, schlagen die Tests fehl werden sie auf Standardwerte gesetzt, die dann wiederum ueber die Weboberflaeche veraendert werden koennen.


wie waer's mit


Dann waer's auch nicht schlecht, wenn man die fehlenden Verzeichnisse ueber die Weboberflaeche gleich mit anlegen koennte.

Grusz Christian.

wieso schreibst du
und nicht ? $self/ kann man webspace nicht!

nach dem ich es so angepasst wie ich es brauch, also aus
$self/foo?bar $self?w=foo;bar gemacht hab, funzt es wunderbar!