Jens: Perl Scripts - hast Du's Dir mal angeschaut Kai???

Beitrag lesen

Hallo,

Also kann ich

  1. das Makefile editieren und per FTP hochladen und
  2. ein CGI-Skript schreiben, welches das Programm in ein Verzeichnis innerhalb _meines_ Webspace installiert.
    Nach (1) sollte (2) schon nicht mehr nötig sein.
    Na gut, das 'make install' zumindest ;-)

Eben - genau um diese eine Zeile geht es aber, die kann ich ohne
Dialogzugang ja nicht eintippen.

Ein Dialog muß es nicht unbedingt sein, aber weniger Aufwand wäre es schon ;-)

Ich muß es dann wahrscheinlich über den vollständigen Pfadnamen
aufrufen, falls ich nicht sogar $PATH entsprechend setzen kann
$PATH kannst Du direkt beim Aufruf setzen:
'PATH="$PATH:/Dein/Pfad/zum/Programm" Programm'

Mir ging es aber um die Verwendung des installierten CPAN-Moduls in
einem später via CGI aufgerufenen Perl-Skript, dessen PATH wahrscheinlich
im Webserver gesetzt (bzw. eingeschränkt) wird.

Ach so, war Mißverständnis meinerseits. Sollte aber kein großes Problem werden, wenn alles im cgi-bin sitzt.
Man beachte aber den Gebrauch des Konjunktivs im letztem Satz ;-)

(Notfalls kann ich mir sogar ein eigenes "make" per FTP hochladen
und per CGI-Skript ausführbar machen ...)
Ja, nur hast Du da das Problem, das Du evt auch noch einen Compiler,
Linker, div Tools auch noch hochladen mußt

Nicht, um einen CPAN-Modul zu übersetzen - in vielen Fällen brauche
ich dazu wirklich nur "make" und "perl".

Im Falle des ImageMagik Paketes reicht das leider nicht, und darum ging es ja. Bei reinen Perlpaketen kannst Du das zu Hause bauen und dann hochschicken. Nach ein wenig ausprobieren und evt Pfaden anpassen sollte es klappen.

Zweite Möglichkeit:
Ein 'make' in Perl. ;-)

Das würde jetzt aber doch zu arg in die Eingeweide gehen um in diesem
Forum (zudem auch noch alles archiviert wird! Schade eigentlich, ich
fand die Idee mit dem Vorschlagen sehr gut. Hat wahrscheinlich das
Archiv um ca 99% entlastet, was? ;-) Platz zu haben.

Ich halte unsere Diskussion für sehr viel archivierungswürdiger als
jede einzelne 2-Frames-Frage.

Das ist aber diskutabel!
SCNR ;-)

Einfach keinen Compiler anzubieten ist wohl die einfachste.

Compiler != make.
Aber in der Tat ist bei vielen kommerziellen UNIXen (AIX, SunOS, ...)
heute der C-Compiler gar nicht mehr im Standardausbau mit drin, sondern
muß separat dazu gekauft werden. (Ich entwickele auf solchen Maschinen,
heul ...)

Sei froh, daß Du nicht mehr auf die Mitgelieferten angewiesen bist. Ich kenne den Schrott zur Genüge der bei verschiedenen Versionen von IRIX, AIX, UNIX, SunOS etc beigepackt wurde und teilweise noch wird.
Aber zur Not gibt es immer noch GCC und die GLibc, obwohl beide nicht gerade das Gelbe vom Ei sind, so sind sie doch besser als o.a. ;-)

Er kann Sorge tragen, daß die Programme im cgi-bin ausschließlich
durch Interpreter gestartet werden,

Wie macht man das? (cgiwrap?)

Ja, am einfachsten durch einen Wrapper. Ich persönlich würde auch einen User/Gruppe 'cgi-bin' einführen, erleichtert einiges.
Ich bin allerdings kein Sysadmin (die Nerven hätte ich nicht ;-) und würde mir eher selber etwas schreiben als erst die Vorhandenen mühsam zu prüfen.

es wäre also nötig den Aufruf in ein Script zu verpacken, das geht
aber nicht, wenn solche Befehle wie system() o.ä. einfach nicht
vorhanden sind.

Ich habe noch nie ein Perl gesehen, welches kein 'system' und keine
backticks und keine Pipes und keine ... besaß. Wie baut man das alles aus?

Auskommentieren.;-)
Aber hier spricht der Programmierer. Einfacher wäre da wohl ein Wrapper namens 'perl' der den auszuführenden Code auf Vorkommen bestimmter Funktionen prüft.
Das ließe sich dann aber evt umgehen, falls der Wrapper nicht sehr sorgfältig programmiert ist. Auskommentieren ist da wohl die sicherste Methode. Bei PHP4 läßt sich IMHO (habe das Dingen schon lange nicht mehr gebaut) einiges schon beim Bauen abschalten.

Was geht es ihn auch an, ob mein CGI-Skript in Perl ein anderes
Perl-Modul oder ein semantisch gleichwertiges C-Programm aufruft?
In einen C-Programm kann man sehr viele Sachen machen, die in Perl
gar nicht, oder nur mit sehr hohem Aufwand möglich sind ...

Yep, das ist klar.
Ich meinte: Wenn ich FTP darf und CGI, dann kann ich ein Binary hochladen
und per CGI das "chmod +x" drauf setzen und dann läuft es.

beckmesserisch, als was Du mich ja mittlerweise kennengelernt hast ;-), würde ich einwenden, das es möglich wäre, daß chmod nicht zur Verfügung steht. Und:ja, es geht auch ohne, daß die Dateien in cgi-bin ausführbar sind.
(einfach via perl starten. Sehr vereinfacht: 'perl script'. Aber wirklich _sehr_ vereinfacht ;-)

(Schlimmsten-
falls mache ich das Einzeiler-Perl-Skript mit system() drum herum, wenn
der Perl-Interpreter nicht sämtliche Möglichkeiten, Prozesse zu starten,
ausgebaut bekommen hat - ein dermaßen abgemagertes wäre die einzige Mög-
lichkeit, den Start beliebiger Programme via CGI zu verhindern.)

Ganz genau. Aber wer macht das schon? ;-)

Außerdem kann ich den Perlinterpreter beschränken, das C-Programm
eher weniger.

Details, bitte? Das interessiert mich sehr.

Den Perlinterpreter kannst Du in seinen Funktionen beschneiden. Auf mehr oder weniger einfache Weise. Siehe auch oben.
Bei Maschinenprogrammen sieht das schon anders aus. Entweder läßt Du sie gar nicht erst zu.oder mußt sie in eine vollständige Sandbox stecken. chroot inklusive aller paranoid-patches für den Kernel und noch einigem mehr.

Die Frage ist doch eher, welche Privilegien meine Benutzerkennung
hat, d. h. ob sie auf /usr/bin lesend zugreifen darf etc.
Dafür gibt es Konzepte wie chroot und Benutzerkennungen/Gruppen;
nichts davon stört mich aber dabei, in meinem _eigenen_ Webspace
Programme zu übersetzen und zu installieren.
Sehr schön. Woher nimmst Du aber den Kompiler, so Du ihn nicht
mitbringst und keine Zugriff auf das System hast?

Das ist lediglich ein bootstrapping-Problem. Wenn ich CGI und system()
im Perl-Interpreter habe, dann bekomme ich (fast) alles zum Laufen

Ja, wenn.

(in USA soll es diverse Provider geben, die socket-Zugriffe unterbinden

Brutal und unnötig.

  • das ist natürlich lästig, dann läuft kein Suchmaschinen-Crawler mehr);

Ja, tut man denn sowas? ;-)))

schlimmstenfalls dauert es halt eine Weile. ;-)

Ja. Ich nehme auch kaum an, das irgendjemand seinen Server so zuschließt, wie ich es tun würde. Meist sind sie dazu fachlich auch gar nicht in der Lage. Aber ein geübter Unix-Sysadmin mit Erfahrung kostet natürlich ein Stange mehr Geld als die 10,50 EUR/Std (muß man sich aber auch erstmal dran gewöhnen EUR zu schreiben ;-), die ein MSCE erwartet >;->

War 'AuthType Basic' nicht einer der 'don't use it's? ;-)
Ein wenig besser kann und sollte es dann doch sein.

Welche Browser unterstützen "AuthType Digest" schon, und ab welcher Version?

Oh wei, jetzt hast Du mich! ;-)
Was ich vermute und auch mal nachprüfen könnte wären Mozilla, Konqueror, w3m, jeweils letzte Version. Bei den beiden Letzgenannten könnte ich es auch zur Not eben einbauen ;-)

(Du könntest ja mal meinen Feature-Artikel auf den neuesten Stand bringen ... ;-)

Na, gut, dann schau ich mal nach und sag es Dir. Kann aber ein paar Tage dauern.

Die zugrunde liegende Idee der o.a. Telnetähnlichen Scripte ist wirklich interessant. Werde mich wohl bei Gelegenheit mal näher damit beschäftigen.

Falls es Dich interessiert - ich habe eines hier.
(368 Zeilen Perl, davon knapp 60% Kommentare.)

Oh, sorgfältig kommentiert?
Dann schicks doch einfach. Kompression nach Belieben, BZip2 bevorzugt.
Adresse oben.

so short

Christoph Zurnieden