Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Perl 5.8.8 deinstallieren, wie?

Perl 5.8.8 deinstallieren, wie?

kix26.02.1122:55
Hallo,

eine App setzt Perl v 5.10.x voraus, hab ich also installiert.

Nun möchte ich das ältere Perl 5.8.8 komplett deinstallieren, bin aber bisher nicht fündig geworden, welche Sachen ich in Terminal eingeben muß, weil die App da "sucht", wo Perl 5.8.8 was abgelegt hat und nicht laufen will.

In den Foren rund um Perl bin ich bisher nicht fündig geworden, vielleicht kann mir hier geholfen werden?
0

Kommentare

derbalu
derbalu26.02.1123:31
Hallo

ich denke es ist nicht so einfach das zu entfernen. Zudem sollte man das nicht tun, denn man weiss nie, welches Tool die Version 5.8.8 nutzt.
Ich denke mal, dass perl5.8 unter /opt/local/bin/ liegt und perl 5.10 unter /usr/bin/

Ich würde zuerst das Kommando 'which perl' das standard-perl finden (/opt/local/bin), dieses umbenennen (mv perl perl_orig) und dann das perl5.10.x hier hin zu linken. (ln -s /usr/bin/perl5.10.0 /opt/local/bin/perl)



„… und täglich grüßt das Murmeltier …“
0
_mäuschen
_mäuschen26.02.1123:42

http://perldoc.perl.org/perlmacosx.html#Starting-From-Scratch

0
kix27.02.1116:54
_mäuschen
Uff, ich hab zunächst alle .bundle(s) von Perl 5.8.1 und 5.8.8 gelöscht. Dank Terminal mit sudo rm und drag&drop der bundles ins Terminal-Fenster gings etwas flotter. Damit hab ich mir immerhin jeweils das obligatorische Admin-Passwort erspart.

derbalu
/opt/ ist ein MacPorts-Ordner und Perl5.8.8 liegt in /usr/bin, siehe unten.
Ich hab‘s mit dem Browser runtergeladen. Installiert hat sich das .dmg dann in /usr/local/ActivePerl-5.10

Im Terminal hab ich danach folgende Befehle eingegeben:

„Last login: Sun Feb 27 15:37:30 on ttys000
kix-imac-g5:~ kix$ which perl
/usr/bin/perl
kix-imac-g5:~ kix$ cd /usr/bin/
kix-imac-g5:bin kix$ mv perl perl orig
usage: mv [-f | -i | -n] [-v] source target
mv [-f | -i | -n] [-v] source ... directory“

Welche Option wende ich in Terminal an?

0
derbalu
derbalu28.02.1110:24
ah, keine leerzeichen im ziel
mit mehr als zwei argumenten, wie du das eingegeben hast, erwartet mv als ziel ein verzeichnis

mv perl perl_orig
„… und täglich grüßt das Murmeltier …“
0
_mäuschen
_mäuschen28.02.1110:25

mv perl "perl orig"

oder

mv perl perl\ orig

oder

mv perl perl_orig


0
sierkb28.02.1110:35
Gelesen und beachtet?

Mac OS X “Snow Leopard” (10.6) and Perl

und vor allem:

Apple Developer: README.macosx - Perl under Mac OS X
, insbesondere auch den Abschnitt "Starting from scratch"
0
kix28.02.1119:16
sierkb, ich hab vergessen, anzugeben, daß ich mit einem iMac PowerPC G5 Version 10.5.8 arbeite.

Der Link zu Apple Developer führt zu einem wortgleichem, also übereinstimmenden Inhalt wie _mäuschens Link zu perldoc.perl.org.


derbalu und _mäuschen

Danke, hab die Eingaben korrigiert.

Mit folgendem Ergebnis:

"Last login: Mon Feb 28 18:13:15 on console
kix-imac-g5:~ kix$ which perl
/usr/bin/perl
kix-imac-g5:~ kix$ cd /usr/bin
kix-imac-g5:bin kix$ sudo mv perl perl_orig
Password:
kix-imac-g5:bin kix$ sudo ln -s /usr/local/ActivePerl-5.10/bin/perl5.10.1 /usr/bin/perl_orig
ln: /usr/bin/perl_orig: File exists

kix-imac-g5:~ kix$ which perl
kix-imac-g5:~ kix$ which perl_orig
/usr/bin/perl_orig
kix-imac-g5:~ kix$ sudo ln -s /usr/local/ActivePerl-5.10/bin/perl5.10.1 /usr/bin/perl_orig
Password:
ln: /usr/bin/perl_orig: File exists"

Äh, ist jetzt mit "File exists" Perl5.10.1 verlinkt?
0
derbalu
derbalu28.02.1121:47
Hihi,

ne aber du hast versucht, die bestehende Datei perl_orig zu überschreiben mit einer Datei, welche als Link fungiert.

Richtig währe ln -s /usr/local/ActivePerl-5.10/bin/perl5.10.1 /usr/bin/perl

perl_orig ist ja nur die Sicherung der originalen Datei 'perl', die ja gemoved wurde

„… und täglich grüßt das Murmeltier …“
0
derbalu
derbalu28.02.1121:54
BTW.

Wieso willst Du eigentlich ein neueres Perl installieren, wenn Du nicht einmal die Unix-Grundlagen kennst ??

„… und täglich grüßt das Murmeltier …“
0
kix28.02.1122:15
derbalu
BTW.

Wieso willst Du eigentlich ein neueres Perl installieren, wenn Du nicht einmal die Unix-Grundlagen kennst ??

Das hab ich doch Eingangs geschrieben, darum wiederhole ich das jetzt nicht. Und daß da tiefere Unix-Kenntnisse bzw. Grundlagen erforderlich sind, stellt sich für mich jetzt erst heraus – ergo ist es mit dem Runterladen und entpacken einer neueren Perl-Version nicht getan … und damit beißt sich die Katze in den Schwanz. Außerdem möchte ich mich nicht rechtfertigen müssen, o.k.?
0
kix28.02.1122:53
Die von ActivePerl 5.10.1 in /usr/local/ActivePerl-5.10/bin hinterlegten Dateien namens perl und perl5.10.1 sind Aliase und laut deren Infofenstern sind beide verlinkt zum im gleichen Ordner /bin befindlichen Original namens perl-dynamic.

Müßte es dann eher heißen

"ln -s /usr/local/ActivePerl-5.10/bin/perl-dynamic /usr/bin/perl"?
0
sierkb28.02.1123:13
Was ich nicht verstehe:

Warum installierst Du eigentlich ein Perl von einer Firma, die sich vor allem auf Perl und derlei Sprachen für das Nicht-Unix-System namens Windows spezialisiert hat?

Warum installierst Du nicht das Perl, das CPAN bzw. Perl.org für Dich bereithält? Oder viele eher: warum installierst Du nicht das Perl, das Apple für Dich bereithält auf Deiner Installations-DVD oder in Apples Download-Bereich unter ?

Bist Du sicher, dass Du Dir einen Gefallen tust mit ActiveState Perl bzw. dass das wirklich das Richtige und Geeignetste ist für MacOSX?
0
sierkb28.02.1123:29
kix:

Und was ich auch nicht verstehe:

Warum rührst Du überhaupt das vom System vorgegebene Perl an? MacOSX braucht das teilweise selber für sich und seinen Betrieb bzw. für das eine oder andere System-Skript, und nach allem was ich weiß, ist dieses vom System vorgegebene Perl sehr auf sich abgestimmt und mag es gar nicht, wenn man es irgendwie durcheinanderbringt oder es von der Versionsnummer her übergebügelt wird mit einer anderen, evtl. neueren Version.
Deshalb bist Du nicht nur von Apple, sondern auch von vielen Entwicklern, die damit ihre leidvollen Erfahrungen haben machen dürfen, gut beraten, das systemeigene Perl dort zu lassen, wo es ist, und wenn Du aus irgendeinem Grund ein weiteres, ein neueres Perl benötigst, es unter /usr/local abzulegen oder Du Dir z.B. (und viel bequemer) MacPorts installierst und Dir mit einem einfachen Kommando à la "sudo port install perl5" ruckzuck von MacPorts automatisch unter /opt/local parallel ein aktuelles Perl 5.12.3 installieren zu lassen mit allen möglichen Standard-Bibliotheken, die das CPAN für eine Standard-Installation so vorsieht. Suchpfad bzw. @INC überprüfen und ggf. den Standard-Suchpfad $PATH anpassen, und fertig ist die Laube.
0
derbalu
derbalu01.03.1108:56
Er will sich doch nicht rechtfertigen.

Sorry, aber es hat auch keiner in Frage gestellt, dass Du einen guten Grund hast, perl 5.10 zu installieren.
Aber perl ist IMHO nun einmal u.a. eine recht wichtige Komponente innerhalb eines Unix-Systems und da sollte man schon
überlegen ob man was ändert.

Und ja, der link muss natürlich auf das gewünschte Binary, also hier perl-dynamic, zeigen.
„… und täglich grüßt das Murmeltier …“
0
kix01.03.1119:05
sierkb
kix:

… einem einfachen Kommando à la "sudo port install perl5" ruckzuck von MacPorts automatisch unter /opt/local parallel ein aktuelles Perl 5.12.3 installieren zu lassen […].

Suchpfad bzw. @INC überprüfen und ggf. den Standard-Suchpfad $PATH anpassen, und fertig ist die Laube.

Danke für den Tipp, MacPorts hat Perl 5.12.2 installiert:

"ppp-xx-xxx-xxx-xx:~ kix$ sudo port install perl5.12
- Configuring perl5.12
- Building perl5.12
- Staging perl5.12 into destroot
- Installing perl5.12 @5.12.2_0
- Activating perl5.12 @5.12.2_0
- Cleaning perl5.12"

Wie überprüfe ich jetzt den "Suchpfad bzw. @INC" und passe "ggf. den Standart-Pfad $PATH" an?




0
kix02.03.1101:48
Vor all meinen Aktionen rund um Perl habe ich per TimeMachine ein Backup gemacht, sei vorangestellt.

So, hab Perl mit MacPorts auf Version 5.12.3 upgegradet und dabei "inaktive Versionen" (5.12.2) per Häckchen setzen in Porticus.app (ein Macports-GUI) – deinstalliert.

Die Verlinkung zu ActivePerl wurde (vorher) aber nicht ausgeführt. Kann ich daher den in /usr/local befindlichen Ordner ActivePerl-5.10 löschen?


0
kix02.03.1121:28
ActivePerl-5.10.1 hab ich mit "~ kix$ sudo /usr/local/ActivePerl-5.10/bin/ap-uninstall" deinstalliert.

Mit dem TimeMachine-Backup wurde das "Bord-"Perl in /System/Library/Perl und /Library/Perl wiederhergestellt, alle .bundles sind also jetzt wieder am Platz.

Mittlerweile ist Perl 5.10.3 da! Hab ich mit MacPorts installiert. So.

Ohne die Fragen von sierkb beantwortet zu haben, bin ich jedoch nicht beratungsresistent und kann lesen bzw. nachlesen und … lernen.

Vielen Dank bis hier hin an derbalu, _mäuschen und sierkb.





0
sierkb02.03.1122:06
kix:

Kleiner Tipp am Rande:

MacPorts ändert die ~/.profile bzw. ~/.bash_profile dahingehend ab, dass es seinen Suchpfad an den Anfang der allgemeinen $PATH-Umgebungsvariablen setzt. Ist auch in dem Installer von MacPorts bzw. in dessen Doku und auch Online-Doku entsprechend vermerkt und ausführlich beschrieben, wieso und warum.

Nicht immer ist das aber gewollt. Ich z.B. will das nicht und habe aus ganz bestimmten Gründen den /opt/local-Pfad von MacPorts ans Ende der $PATH-Umgebungsvariablen gesetzt (weil ich, wenn es Überschneidungen und Gleichheiten geben sollte zwischen unter MacPorts installierter Software und Bibliotheken und den MacOSX-eigenen Programmen und Bibliotheken, lieber gerne die vom System bereitgestellte Version standardmäßig verwendet wissen will und nicht das unter MacPorts bzw. /opt/local liegende Doppel). Im Allgemeinen ist es wohl eher ratsam, der von MacPorts vorgeschlagene und standardmäßig so eingerichtete Reihenfolge bzgl. $PATH zu vertrauen und es so zu lassen, wie MacPorts es da eingerichtet hat.

Das allgemein zu MacPorts und $PATH.

Was die Suchpfade speziell für Perl und CPAN Perl-Moduln angeht (@INC), so habe ich Folgendes gemacht: damit das systemeigene Perl und dessen CPAN-Moduln auch die von MacPorts installierten CPAN-Moduln finden kann und in seinen allgemeinen @INC-Suchpfad mit integrieren kann, habe ich auf der Suche nach einer Lösungsmöglichkeit folgenden Ort und folgende Datei entdeckt:

/Library/Perl/5.10.0/AppendToPath

Von dieser Datei habe ich eine Sicherheitskopie gemacht und habe dem Inhalt dieser Datei schlicht und einfach folgende Pfade hinzugefügt (ich habe per MacPorts ganz bewusst ein Perl 5.10.1 installiert, obwohl seit neuestem das Default-Perl von MacPorts bereits die Version 5.12 ist):

/opt/local/lib/perl5/5.10.1
/opt/local/lib/perl5/site_perl/5.10.1
/opt/local/lib/perl5/vendor_perl/5.10.1

Sprich: der systemeigene Perl-Suchpfad @Inc hängt diese Pfade an das Ende seines systemeigenen @INC-Suchpfads und weiß auf diese Weise von der Existenz meiner unter /opt/local angelegten CPAN Perl-Moduln. Mehr will ich nicht, und das Ergebnis ist genau das, was ich haben will.

Will man etwas an den Anfang des @INC-Suchpfades legen, so müsste man das in die Datei /Library/Perl/5.10.0/PrependToPath reinschreiben, die standardmäßig nicht existiert und die man erstmal erstellen müsste. Standardmäßig existiert nur /Library/Perl/5.10.0/AppendToPath mit einer einzigen Zeile: /System/Library/Perl/Extras/5.10.0, die ich wie gerade genannt um meine Pfade ergänzt habe.

Details und Hintergrund des Ganzen ist online hier nachzulesen im Abschnitt "Customizations in Apple's Perl, Module Search Path (@INC)" oder im Terminal mit $ man perlmacosx.

Das hat Apple erst irgendwann im Laufe von MacOSX Leopard eingeführt, weil es teilweise ganz große und verheerende Kompikationen gab, wenn man sich aus dem CPAN Perl-Module installiert hatte, die dann regelmäßig das systemeigene Perl und dessen CPAN-Module zerschossen und überschrieben, sodass da teilweise nicht mehr ordentlich mit zu arbeiten war. Seit diesem Drama hat Apple das sauber getrennt und dem Systemadmin bzw. root das Verzeichnis /Library/Perl als Standard eingestellt, welches dann die Pfade im Nachhinein unter /System/Library/Perl einbindet und die Perl-Moduln unter /System/Library/Perl damit im Nachinein erst einbindet. Vorher war's wohl umgekehrt, und Installationen über CPAN hat dann regelmäßig in /System/Library/Perl herumgefuddelt und da für Unordnung gesorgt, weil MacOSX teilweise aus bestimmten Gründen nur ganz bestimmte Versionen von Perl-Moduln verwendet und auf diese angewiesen ist. Wenn diese mit neueren oder neu und anders kompilierten Binär-Bibliotheken überschrieben wurden, hat's dann an vielen Stellen gerummst.
Also hat Apple seine Perl-Installation grundlegend überarbeitet bzw. sich u.a. das mit AppendToPath und PrependToPath einfallen lassen, und seitdem kann man nun auch mit einigermaßem ruhigen Gewissen sich Perl-Module aus dem CPAN installieren, die dann brav unter /Library/Perl abgelegt werden (und nicht mehr unter /System/Library/Perl) bzw. deren Manpages unter /usr/local/share/man statt wie früher unter /usr/share/man.

Lies Dir die oben angegebene Manpage mal am besten durch, das macht Einiges klarer.
Ebenso bzgl. der Doku zu MacPorts, die online hier zu finden ist: .


0
kix04.03.1114:36
An die Verlinkung mit (den vorgeschlagenen) Umgebungsvariablen hab ich mich bisher noch nicht herangemacht, stelle ich voran. Da muß ich erst noch was lesen, wie sierkb anregt.

Mittlerweile hab ich via MacPorts Perl 5.12.3 wieder deinstalliert und dann Perl 5.10.1 kompiliert, denn die – Eingangs erwähnte – App erfordert ja die Perl-Moduln „Log4perl“:

„/Library/Perl/5.10.0/Log/Log4perl/
/Library/Perl/5.10.0/Log/Log4perl.pm
/usr/local/share/man/man1/l4p-tmpl.1
/usr/local/share/man/man3/Log::Log4perl*“

- In /Library/Perl/ sind aktuell die Ordner /5.8.1, /5.8.8, /Updates und die Zip-Datei „archived_perl.cpio.bz2“ enthalten.

- „l4p-tmpl.1“ wird von den Suchprogrammen FindAnyFile und EasyFind nicht gefunden. Ist das eine Datei speziell von Perl 5.10.0 (MacPorts kompiliert „nur“ Perl 5.10.1 und nicht mehr die Vorgängerversion 5.10.0)?

- Die Log::Log4perl*-Dateien sind im man3-Ordner hinterlegt und zwar von „Bord“-Perl 5.8.1 und/oder 5.8.8, nehme ich an. Ob o.k., weiss ich nicht, weil die jene Dateien in den betreffenden Ordnern voraussetzende App (noch) nicht getestet wurde …
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.