Ich habe bisher eigentlich nur neue Active-State-Perl-Versionen eingespielt und unter Linux das verwendet, was bei der Distribution dabei war.

Nun würde ich aber gerne mal die aktuelle Perl-Version (8.4 ?) installieren, und dann möglichst auch eine passende aktuelle Perl/Tk-Version.

Ich habe mir das so gedacht, dass ich das neue Perl irgendwo in ein passend benanntes Verzeichnis mit klar erkennbarer Version installiere, den alten Link (oder ausführbare Datei?) unter /usr/bin umbenne und einen neuen link (oder ausführbare Datei) auf das neue perl dort unterbringe, so dass man per default die neue Perlversion verwendet, auf die andere aber noch Zugriff hat.

Fragen: Wo bekomme ich die Perl und Perl/Tk-Versionen am besten her, CPAN? www.perl.org?

Und sollte ich die Umbenennung vor dem installieren machen, damit mir das alte Perl nicht verloren geht?


Andere Frage: Ich muss unter Perl immer die Perlskripte mit perl meinskript.pl starten, ich würde gerne auf das perl vorweg verzichten können. Ich habe in der Shebang den richtigen Pfad und den Skripten mit chmod 755 auch die richtigen Rechte zum Ausführen gegeben, trotzdem wollen sie nicht ;-)

dann mach mal ./skript.pl (wichtig ist das ./ )...

Hier bekommst Du Perl: http://dev.perl.org/perl5/news/2004/perl-5.8.4.html\n\n

<!--EDIT|renee|1086175025-->

halte ich für einen guten plan, die alte version zu behalten - sollte gehen, wie du es beschreibst.
umbenennung vor dem installieren finde ich auch sinnvoll, die libs bleiben ja ohnehin unangetastet, da versionsnummer im verzeichnisnamen.
perl im src holst du dir zum beispiel von http://www.perl.com/download.csp und installierst es, die einstellungen werden während der installation vorgenommen (ansonsten readme lesen ;).

zur anderen frage: was wollen sie denn nicht / wie teilen sie dir das mit?
hast du mal zB ./script.pl statt nur script.pl versucht oder /pfad/zum/script/script.pl? mit der richtigen shebang und ausführbaren rechten sollte das gehen!

Ich installiere ein neues Perl immer in ein eigenes Verzeichnis. Beim Konfigurieren von perl verwende ich:

Falls ich noch eine Debugging- oder Threads-Version baue, kommen diese nach /usr/perl5.8.4d bzw. /usr/perl5.8.4t. Um die neue Version zu verwenden, muss ich entweder haendisch #!/usr/perl5.8.4/bin/perl in die Skripte eintragen, oder /usr/perl5.8.4/bin in meinen PATH vorne unterbringen und #!/usr/bin/env perl in die Skripte eintragen, oder Symlinks von /usr/bin/perl nach /usr/perl5.8.4/bin/perl etc. erzeugen.

Um die gleichen CPAN-Module wie bei der alten Perl-Version zu installieren, kann man die "autobundle"-Funktion von CPAN.pm verwenden. Leider funktioniert das automatische Upgrade damit nicht so gut, weil viele Tests nicht ohne "force" durchlaufen (z.B. DBD::mysql).

Kann sein, dass ich nicht auf ./ davor gekommen bin, weiß nicht mehr genau und kann es jetzt gerade nicht testen :-(

Aber dann pack ich mal lieber ein export $PATH=$PATH:. in die .bashrc ... ich bins von früher so gewohnt, dass ich als User das aktuelle Verzeichnis ganz hinten im Pfad hab (als root natürlich nicht).

Ich hatte schon gehofft, dass die Verzeichnisse mit dem eigentlichen Perl die Nummern beinhalten. /usr/bin/perl ist doch wahrscheinlich ein Link, oder? (Wieso muss ich hier an Windows arbeiten? ...^^...)

Meistens ist /usr/bin/perl ein Hardlink auf /usr/bin/perl$perlversion.

bei Unix/Linux habe ich die erfahrung gemacht, dass es oft nicht gut ist, wenn man das installierte perl updated, weil da i.d.R. viele Betriebssystemscripte davon abhaengen, und dann ueberpruefen, ob nachher noch alles reibungslos funktioniert, ist meistens recht aufwendig...
Stattdessen installiere ich gerne eine Perl-Version parallel dazu (z.B. nach /opt/perl5.8.4/ oder /usr/local/perl oder so und achte dabei, dass der link /usr/bin/perl nicht ueberschrieben wird, damit das alte noch alles funktioniert). in /usr/bin/ setze ich nur einen Link, der z.B. perl5.8.3 oder so heisst, und auf die ich nur einen Link /usr/bin/perl5.8.3 oder so setze, damit ich als shebang /usr/bin/perl5.8.3 verwenden kann. wenn dieses Perl nur von einem (oder mehreren) usern verwendet werden soll, dann kann man /opt/perl/bin auch in PATH vor /usr/bin stellen (muss man nur bei cronjobs aufpassen, dass der gesetzt ist) und dann als shebang einfach !# perl zu verwenden...

Gute Idee, oder man macht sich einen Link in ~/bin, der gilt dann nur für den User, und zumindestens bei mir ist ~/bin vor /usr/bin/ im Pfad.

Ich hab jetzt unter SuSE 9.0 Perl 5.8.1 und 5.8.4 und unter SuSE 9.1 (das ich mir gekauft habe) Perl 5.8.3. Dort werde ich auch noch die 5.8.4er Version nachziehen.

(Ich hab jetzt 4 Betriebssyteme auf dem Rechner, neben den beiden Linuxen noch Windows 98SE und XP home für Spielkram... Ich hoffe der Trend von Unreal Tournament 2004 (kann man einfach sowohl unter Linux als auch unter Windows installieren aus der gleichen Packung heraus) setzt sich fort. (Da warte ich aber noch, dass es deutlich billiger als 44 Euro wird...)

so aus reinem interesse: warum lässt du suse 9.0 und 9.1 parallel laufen? gibt's da massive unterschiede oder planst du längerfristig einen umstieg?

Es gibt schon ein paar Neuerungen.
Die neue KDE Version ist u.a. implementiert, die einige Bugs der Vorgängerversion behebt. Neue Treiber und viele Packages sind auf der CD enthalten.
Was mich etwas wundert ist, dass man ab 9.1 seine Geräte nicht mehr mounten muss. Das geschieht jetzt alles automatisch. mount wird also überflüssig. Ob das ein Vorteil ist, weiß ich nicht.