Kurz: In dieser detaillierten Anleitung wird erläutert, wie Sie ein Programm aus dem Quellcode Linux und wie die Software aus dem Quellcode installiert zu entfernen.

Eine der größten Stärken Ihrer Linux-Distribution ist der Paketmanager und das zugehörige Software-Repository. Mit ihnen verfügen Sie über alle erforderlichen Tools und Ressourcen, um neue Software vollständig automatisiert herunterzuladen und auf Ihrem Computer zu installieren.

Aber trotz aller Bemühungen können die Paketbetreuer nicht jeden einzelnen Anwendungsfall behandeln. Sie können auch nicht die gesamte verfügbare Software verpacken. Es gibt also immer noch Situationen, in denen Sie neue Software selbst kompilieren und installieren müssen. Für mich ist der häufigste Grund, warum ich Software kompilieren muss, wenn ich eine ganz bestimmte Version ausführen oder den Quellcode mithilfe einiger ausgefallener Kompilierungsoptionen ändern muss.

Wenn Ihre Bedürfnisse zur letzteren Kategorie gehören, wissen Sie wahrscheinlich bereits, was zu tun ist. Für die überwiegende Mehrheit der Linux-Benutzer könnte das Kompilieren und Installieren von Software aus dem Quellcode zum ersten Mal wie eine Initiationszeremonie aussehen: etwas beängstigend; aber mit dem Versprechen, eine neue Welt der Möglichkeiten und einen Prestigeplatz in einer privilegierten Gemeinschaft zu betreten.

A. Installieren von Software aus dem Quellcode unter Linux

Und genau das werden wir hier tun. Nehmen wir für die Zwecke dieses Artikels an, ich muss NodeJS 8.1.1 auf meinem System installieren. Genau diese Version. Eine Version, die nicht im Debian-Repository verfügbar ist:

sh$ apt-cache madison nodejs | grep amd64 nodejs | 6.11.1~dfsg-1 | http://deb.debian.org/debian experimental/main amd64 Packages nodejs | 4.8.2~dfsg-1 | http://ftp.fr.debian.org/debian stretch/main amd64 Packages nodejs | 4.8.2~dfsg-1~bpo8+1 | http://ftp.fr.debian.org/debian jessie-backports/main amd64 Packages nodejs | 0.10.29~dfsg-2 | http://ftp.fr.debian.org/debian jessie/main amd64 Packages nodejs | 0.10.29~dfsg-1~bpo70+1 | http://ftp.fr.debian.org/debian wheezy-backports/main amd64 Packages

Die Installation von NodeJS unter Ubuntu oder Debian ist jetzt ziemlich einfach, wenn Sie dies mit dem Paketmanager tun. Aber machen wir es über den Quellcode.

Schritt 1: Abrufen des Quellcodes von GitHub

Wie bei vielen Open-Source-Projekten finden Sie die Quellen von NodeJS auf GitHub: https://github.com/nodejs/node

Gehen wir also direkt dorthin.

Wenn Sie mit GitHub, git oder einem anderen erwähnenswerten Versionskontrollsystem nicht vertraut sind, enthält das Repository die aktuelle Quelle für die Software sowie eine Historie aller Änderungen, die im Laufe der Jahre an dieser Software vorgenommen wurden. Schließlich bis zur allerersten Zeile, die für dieses Projekt geschrieben wurde. Für die Entwickler hat das Beibehalten dieser Historie viele Vorteile. Für uns heute ist das Wichtigste, dass wir in der Lage sein werden, die Quellen für das Projekt so zu erhalten, wie sie zu einem bestimmten Zeitpunkt waren. Genauer gesagt, ich werde in der Lage sein, die Quellen so zu erhalten, wie sie waren, als die gewünschte 8.1.1-Version veröffentlicht wurde. Auch wenn es seitdem viele Modifikationen gab.

Auf GitHub können Sie mit der Schaltfläche „branch“ zwischen verschiedenen Versionen der Software navigieren. „Branch“ und „Tags“ sind etwas verwandte Konzepte in Git. Grundsätzlich erstellen die Entwickler „Branch“ und „Tags“, um wichtige Ereignisse im Projektverlauf zu verfolgen, z. B. wenn sie mit der Arbeit an einem neuen Feature beginnen oder wenn sie ein Release veröffentlichen. Ich werde hier nicht auf die Details eingehen, alles, was Sie wissen müssen, ist, dass ich nach der Version mit dem Tag „v8.1.1“ suche

achdem auf dem „v8.1.1“-Tag wird die Seite aktualisiert, wobei die offensichtlichste Änderung darin besteht, dass das Tag jetzt als Teil der URL angezeigt wird. Darüber hinaus werden Sie feststellen, dass das Änderungsdatum der Datei ebenfalls unterschiedlich ist. Der Quellbaum, den Sie jetzt sehen, ist der, der zum Zeitpunkt der Erstellung des v8.1.1-Tags vorhanden war. In gewissem Sinne können Sie sich ein Versionskontrolltool wie git als Zeitreisemaschine vorstellen, mit der Sie in eine Projekthistorie hin und her gehen können.

An dieser Stelle können wir die Quellen von NodeJS 8.1.1 herunterladen. Sie können den großen blauen Knopf nicht verpassen, der vorschlägt, das ZIP-Archiv des Projekts herunterzuladen. Was mich betrifft, werde ich die ZIP-Datei aus Gründen der Erklärung von der Befehlszeile herunterladen und extrahieren. Wenn Sie jedoch lieber ein GUI-Tool verwenden möchten, zögern Sie nicht, dies stattdessen zu tun:

wget https://github.com/nodejs/node/archive/v8.1.1.zipunzip v8.1.1.zipcd node-8.1.1/

Das Herunterladen des ZIP-Archivs funktioniert hervorragend. Aber wenn Sie es „wie ein Profi“ machen wollen, würde ich vorschlagen, direkt das git Tool zu verwenden, um die Quellen herunterzuladen. Es ist überhaupt nicht kompliziert — und es wird ein netter erster Kontakt mit einem Werkzeug sein, dem Sie oft begegnen werden:

# first ensure git is installed on your systemsh$ sudo apt-get install git# Make a shallow clone the NodeJS repository at v8.1.1sh$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/nodesh$ cd node/

Übrigens, wenn Sie ein Problem haben, betrachten Sie einfach den ersten Teil dieses Artikels als allgemeine Einführung. Später habe ich detailliertere Erklärungen für Debian- und RedHat-basierte Distributionen, um Ihnen bei der Behebung häufiger Probleme zu helfen.

Wie auch immer, wenn Sie die Quelle mit git oder als ZIP-Archiv heruntergeladen haben, sollten Sie jetzt genau die gleichen Quelldateien im aktuellen Verzeichnis haben:

sh$ lsandroid-configure BUILDING.md common.gypi doc Makefile srcAUTHORS CHANGELOG.md configure GOVERNANCE.md node.gyp testbenchmark CODE_OF_CONDUCT.md CONTRIBUTING.md lib node.gypi toolsBSDmakefile COLLABORATOR_GUIDE.md deps LICENSE README.md vcbuild.bat

Schritt 2: Verständnis des Build-Systems des Programms

Normalerweise sprechen wir über „Kompilieren der Quellen“, aber die Kompilierung ist nur eine der Phasen, die erforderlich sind, um eine funktionierende Software aus der Quelle. Ein Build-System ist eine Reihe von Tools und Praktiken, die verwendet werden, um diese verschiedenen Aufgaben zu automatisieren und zu artikulieren, um die Software vollständig zu erstellen, indem nur wenige Befehle ausgegeben werden.

Wenn das Konzept einfach ist, ist die Realität etwas komplizierter. Weil unterschiedliche Projekte oder Programmiersprachen unterschiedliche Anforderungen haben können. Oder wegen des Geschmacks des Programmierers. Oder die unterstützten Plattformen. Oder aus historischen Gründen. Oder … oder.. es gibt eine fast endlose Liste von Gründen, ein anderes Build-System zu wählen oder zu erstellen. All das zu sagen, es gibt viele verschiedene Lösungen, die da draußen verwendet werden.NodeJS verwendet ein Build-System im GNU-Stil, es ist eine beliebte Wahl in der Open-Source-Community und wieder einmal ein guter Weg, um Ihre Reise zu beginnen.

Das Schreiben und Optimieren eines Build-Systems ist eine ziemlich komplexe Aufgabe, aber für den „Endbenutzer“ erleichtern Build-Systeme im GNU-Stil die Aufgabe, indem sie zwei Werkzeuge verwenden: configure und make.

Die configure -Datei ist ein projektspezifisches Skript, das die Konfiguration des Zielsystems und die verfügbaren Funktionen überprüft, um sicherzustellen, dass das Projekt erstellt werden kann.

Ein wichtiger Teil einer typischen configure Aufgabe ist es, die Makefile zu erstellen. Dies ist die Datei, die die Anweisungen enthält, die zum effektiven Erstellen des Projekts erforderlich sind.

Das make -Tool hingegen ist ein POSIX-Tool, das auf jedem Unix-ähnlichen System verfügbar ist. Es liest die projektspezifische Makefile und führt die erforderlichen Vorgänge zum Erstellen und Installieren Ihres Programms aus.

Aber wie immer in der Linux-Welt haben Sie immer noch eine gewisse Nachsicht, wenn Sie den Build an Ihre spezifischen Bedürfnisse anpassen.

./configure --help

Der Befehl configure -help zeigt Ihnen alle verfügbaren Konfigurationsoptionen. Dies ist wiederum sehr projektspezifisch. Und um ehrlich zu sein, ist es manchmal notwendig, sich mit dem Projekt zu befassen, bevor man die Bedeutung jeder einzelnen Konfigurationsoption vollständig versteht.

Aber es gibt mindestens eine Standard GNU Autotools Option, die Sie kennen müssen: die --prefix Option. Dies hat mit der Dateisystemhierarchie und dem Ort zu tun, an dem Ihre Software installiert wird.

Schritt 3: Die FHS

Die Linux-Dateisystemhierarchie einer typischen Distribution entspricht größtenteils dem Filesystem Hierarchy Standard (FHS)

Dieser Standard erklärt den Zweck der verschiedenen Verzeichnisse Ihres Systems: /usr/tmp/var und so weiter.

Wenn Sie die GNU Autotools — und die meisten anderen Build—Systeme – verwenden, ist der Standardinstallationsort für Ihre neue Software /usr/local. Welches ist eine gute Wahl, da laut FSH „Die Hierarchie / usr / local vom Systemadministrator verwendet wird, wenn Software lokal installiert wird? Es muss sicher sein, dass es nicht überschrieben wird, wenn die Systemsoftware aktualisiert wird. Es kann für Programme und Daten verwendet werden, die von einer Gruppe von Hosts gemeinsam genutzt werden können, aber nicht in / usr zu finden sind.“

Die /usr/local Hierarchie repliziert irgendwie das Stammverzeichnis, und Sie finden dort /usr/local/bin für die ausführbaren Programme, /usr/local/lib für die Bibliotheken, /usr/local/share für architekturunabhängige Dateien und so weiter.

Das einzige Problem bei der Verwendung des /usr/local -Baums für die benutzerdefinierte Softwareinstallation ist, dass die Dateien für Ihre gesamte Software dort gemischt werden. Insbesondere nach der Installation einiger Software wird es schwierig sein zu verfolgen, zu welcher Datei genau von /usr/local/bin und /usr/local/lib gehört zu welcher Software. Das wird jedoch kein Problem für das System verursachen. Immerhin ist /usr/bin ungefähr das gleiche Durcheinander. Dies wird jedoch an dem Tag zu einem Problem, an dem Sie eine manuell installierte Software entfernen möchten.

Um dieses Problem zu lösen, ziehe ich es normalerweise vor, benutzerdefinierte Software stattdessen im /opt -Unterbaum zu installieren. Noch einmal, um die FHS zu zitieren:

_“/opt ist für die Installation von Add-On-Anwendungssoftware-Paketen reserviert.

Ein Paket, das in /opt installiert werden soll, muss seine statischen Dateien in einem separaten /opt/<Paket> oder /opt/<provider> Verzeichnisbaum finden, wobei <Paket> ist ein Name, der das Softwarepaket beschreibt, und <Anbieter> ist der LANANA-registrierte Name des Anbieters.“_

Also werden wir ein Unterverzeichnis von /opt speziell für unsere benutzerdefinierte NodeJS-Installation erstellen. Und wenn ich eines Tages diese Software entfernen möchte, muss ich einfach dieses Verzeichnis entfernen:

sh$ sudo mkdir /opt/node-v8.1.1sh$ sudo ln -sT node-v8.1.1 /opt/node# What is the purpose of the symbolic link above?# Read the article till the end--then try to answer that# question in the comment section!sh$ ./configure --prefix=/opt/node-v8.1.1sh$ make -j9 && echo ok# -j9 means run up to 9 parallel tasks to build the software.# As a rule of thumb, use -j(N+1) where N is the number of cores# of your system. That will maximize the CPU usage (one task per# CPU thread/core + a provision of one extra task when a process# is blocked by an I/O operation.

Alles andere als „ok“, nachdem der Befehl make abgeschlossen wurde, würde bedeuten, dass während des Erstellungsprozesses ein Fehler aufgetreten ist. Da wir aufgrund der Option -j einen parallelen Build ausgeführt haben, ist es angesichts des großen Ausgabevolumens des Build-Systems nicht immer einfach, die Fehlermeldung abzurufen.

Im Falle eines Problems starten Sie einfach make neu, diesmal jedoch ohne die Option -j. Und der Fehler sollte am Ende der Ausgabe erscheinen:

sh$ make

Sobald die Kompilierung abgeschlossen ist, können Sie Ihre Software an ihrem Speicherort installieren, indem Sie den folgenden Befehl ausführen:

sh$ sudo make install

Und testen Sie es:

sh$ /opt/node/bin/node --versionv8.1.1

B. Was ist, wenn bei der Installation aus dem Quellcode etwas schief geht?

Was ich oben erklärt habe, ist hauptsächlich das, was Sie auf der Seite „Build instruction“ eines gut dokumentierten Projekts sehen können. Angesichts des Ziels dieses Artikels ist es jedoch, dass Sie Ihre erste Software aus Quellen kompilieren können, Es könnte sich lohnen, sich die Zeit zu nehmen, um einige häufige Probleme zu untersuchen. Also werde ich den gesamten Vorgang noch einmal durchführen, diesmal jedoch von einem frischen und minimalen Debian 9.0- und CentOS 7.0-System aus, damit Sie die aufgetretenen Fehler und deren Lösung sehen können.

Von Debian 9.0 „Stretch“

:~$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node-bash: git: command not found

Dieses Problem ist recht einfach zu diagnostizieren und zu lösen. Installieren Sie einfach das git Paket:

:~$ sudo apt-get install git

:~$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node && echo okok

:~/node$ sudo mkdir /opt/node-v8.1.1:~/node$ sudo ln -sT node-v8.1.1 /opt/node

Kein Problem hier.

:~/node$ ./configure --prefix=/opt/node-v8.1.1/WARNING: failed to autodetect C++ compiler version (CXX=g++)WARNING: failed to autodetect C compiler version (CC=gcc)Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix.

Um ein Projekt zu kompilieren, benötigen Sie natürlich einen Compiler. Da NodeJS in der Sprache C ++ geschrieben wurde, benötigen wir einen C ++ – Compiler. Hier installiere ich `g++`, den GNU C++ Compiler für diesen Zweck:

:~/node$ sudo apt-get install g++:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo okok

:~/node$ make -j9 && echo ok-bash: make: command not found

Ein weiteres fehlendes Tool. Gleiche Symptome. Gleiche Lösung:

:~/node$ sudo apt-get install make:~/node$ make -j9 && echo okok

:~/node$ sudo make install:~/node$ /opt/node/bin/node --versionv8.1.1

Erfolg!

Bitte beachten Sie: Ich habe die verschiedenen Tools nacheinander installiert, um zu zeigen, wie die Kompilierungsprobleme diagnostiziert werden, und um Ihnen die typische Lösung zur Lösung dieser Probleme zu zeigen. Wenn Sie jedoch nach weiteren Informationen zum Thema suchen oder andere Tutorials lesen, werden Sie feststellen, dass die meisten Distributionen über „Metapakete“ verfügen, die als Dach für die Installation einiger oder aller typischen Tools zum Kompilieren einer Software dienen. Auf Debian-basierten Systemen werden Sie wahrscheinlich auf das build-essentials-Paket für diesen Zweck stoßen. Und auf Red-Hat-basierten Distributionen wird das die Gruppe „Entwicklungstools“ sein.

Von CentOS 7.0

 ~]$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node-bash: git: command not found

Befehl nicht gefunden? Installieren Sie es einfach mit dem yum Paketmanager:

 ~]$ sudo yum install git

 ~]$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node && echo okok

 ~]$ sudo mkdir /opt/node-v8.1.1 ~]$ sudo ln -sT node-v8.1.1 /opt/node

 ~]$ cd node node]$ ./configure --prefix=/opt/node-v8.1.1/WARNING: failed to autodetect C++ compiler version (CXX=g++)WARNING: failed to autodetect C compiler version (CC=gcc)Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix.

Sie erraten es: NodeJS ist in der Sprache C ++ geschrieben, aber meinem System fehlt der entsprechende Compiler. Yum zur Rettung. Da ich kein normaler CentOS-Benutzer bin, musste ich im Internet nach dem genauen Namen des Pakets suchen, das den g ++ – Compiler enthält. Führt mich zu dieser Seite: https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

 node]$ sudo yum install gcc-c++ node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo okok

 node]$ make -j9 && echo okok

 node]$ sudo make install && echo okok

 node]$ /opt/node/bin/node --versionv8.1.1

Erfolg. Wieder.

C. Änderungen an der aus dem Quellcode installierten Software vornehmen

Sie können Software aus dem Quellcode installieren, weil Sie eine ganz bestimmte Version benötigen, die in Ihrem Distributions-Repository nicht verfügbar ist, oder weil Sie das Programm ändern möchten, um einen Fehler zu beheben oder eine Funktion hinzuzufügen. Schließlich geht es bei Open Source darum, Änderungen vorzunehmen. Ich werde diese Gelegenheit nutzen, um Ihnen einen Vorgeschmack auf die Leistung zu geben, die Sie jetzt zur Hand haben, da Sie Ihre eigene Software kompilieren können.

Hier werden wir eine kleine Änderung an den Quellen von NodeJS vornehmen. Und wir werden sehen, ob unsere Änderung in die kompilierte Version der Software integriert wird:

Öffnen Sie die Datei node/src/node.cc in Ihrem bevorzugten Texteditor (vim, nano, gedit, …). Und versuchen Sie, dieses Codefragment zu finden:

 if (debug_options.ParseOption(argv, arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) { printf("%s\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp(); exit(0); }

Es befindet sich in Zeile 3830 der Datei. Ändern Sie dann die Zeile mit printf so, dass sie stattdessen mit dieser übereinstimmt:

 printf("%s (compiled by myself)\n", NODE_VERSION);

Dann geh zurück zu deinem Terminal. Bevor Sie fortfahren — und um Ihnen einen besseren Einblick in die Leistungsfähigkeit von git zu geben — können Sie überprüfen, ob Sie die richtige Datei geändert haben:

diff --git a/src/node.cc b/src/node.ccindex bbce1022..a5618b57 100644--- a/src/node.cc+++ b/src/node.cc@@ -3828,7 +3828,7 @@ static void ParseArgs(int* argc, if (debug_options.ParseOption(argv, arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) {- printf("%s\n", NODE_VERSION);+ printf("%s (compiled by myself)\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp();

Sie sollten ein „-“ (Minuszeichen) vor der Zeile sehen, wie es war, bevor Sie es geändert haben. Und ein „+“ (Pluszeichen) vor der Zeile nach Ihren Änderungen.

Es ist jetzt an der Zeit, Ihre Software neu zu kompilieren und neu zu installieren:

make -j9 && sudo make install && echo okok

Diesmal kann es nur fehlschlagen, dass Sie beim Ändern des Codes einen Tippfehler gemacht haben. Wenn dies der Fall ist, öffnen Sie die Datei node/src/node.cc erneut in Ihrem Texteditor und beheben Sie den Fehler.

Sobald Sie es geschafft haben, diese neue modifizierte NodeJS-Version zu kompilieren und zu installieren, können Sie überprüfen, ob Ihre Änderungen tatsächlich in die Software integriert wurden:

:~/node$ /opt/node/bin/node --versionv8.1.1 (compiled by myself)

Herzlichen Glückwunsch! Sie haben Ihre erste Änderung an einem Open-Source-Programm vorgenommen!

D. Lassen Sie die Shell unsere benutzerdefinierte Build-Software finden

Sie haben vielleicht bemerkt, dass ich meine neu kompilierte NodeJS-Software immer gestartet habe, indem ich den absoluten Pfad zur Binärdatei angegeben habe.

/opt/node/bin/node

Es funktioniert. Aber das ist ärgerlich, gelinde gesagt. Es gibt tatsächlich zwei gängige Möglichkeiten, dies zu beheben.

Es gibt eigentlich zwei gängige Möglichkeiten, das lästige Problem der Angabe des absoluten Pfades zu den Binärdateien zu beheben,
aber um sie zu verstehen, müssen Sie zuerst wissen, dass Ihre Shell die ausführbaren Dateien findet, indem Sie sie nur in den Verzeichnissen sucht, die durch die Umgebungsvariable PATH angegeben werden.

:~/node$ echo $PATH/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Wenn Sie hier auf diesem Debian-System kein Verzeichnis explizit als Teil eines Befehlsnamens angeben, sucht die Shell zuerst nach den ausführbaren Programmen in /usr/local/bin, dann, wenn nicht gefunden, in /usr/bin, dann, wenn nicht gefunden, in /bin dann, wenn nicht gefunden in /usr/local/games dann, wenn nicht gefunden in /usr/games, dann, wenn nicht gefunden … die Shell meldet einen Fehler „Befehl nicht gefunden“.

In Anbetracht dessen haben wir zwei Möglichkeiten, einen Befehl für die Shell zugänglich zu machen: indem Sie es zu einem der bereits konfigurierten PATH Verzeichnisse hinzufügen. Oder indem Sie das Verzeichnis, das unsere ausführbare Datei enthält, zu PATH hinzufügen.

Hinzufügen eines Links von /usr/local/bin

Kopieren Sie einfach die ausführbare Node-Binärdatei von /opt/node/bin nach /usr/local/bin wäre eine schlechte Idee, da das ausführbare Programm dadurch nicht mehr in der Lage wäre, die anderen erforderlichen Komponenten von /opt/node/ b. für Software, um ihre Ressourcendateien relativ zu ihrem eigenen Speicherort zu lokalisieren).

Die traditionelle Art, dies zu tun, ist die Verwendung eines symbolischen Links:

:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node:~/node$ which -a node || echo not found/usr/local/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)

Dies ist eine einfache und effektive Lösung, insbesondere wenn ein Softwarepaket nur aus wenigen bekannten ausführbaren Programmen besteht — da Sie für jeden vom Benutzer aufrufbaren Befehl einen symbolischen Link erstellen müssen. Wenn Sie beispielsweise mit NodeJS vertraut sind, kennen Sie auch die npm Begleitanwendung, die ich von /usr/local/bin symlink sollte. Aber das lasse ich dir als Übung.

Ändern des PFADES

Wenn Sie die vorhergehende Lösung ausprobiert haben, entfernen Sie zunächst den zuvor erstellten symbolischen Link des Knotens, um von einem klaren Zustand aus zu starten:

:~/node$ sudo rm /usr/local/bin/node:~/node$ which -a node || echo not foundnot found

Und jetzt ist hier der magische Befehl zum Ändern Ihrer PATH:

:~/node$ export PATH="/opt/node/bin:${PATH}":~/node$ echo $PATH/opt/node/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Einfach gesagt, ich habe den Inhalt der Umgebungsvariablen PATH durch den vorherigen Inhalt ersetzt, jedoch mit dem Präfix /opt/node/bin . Wie Sie sich jetzt vorstellen können, sucht die Shell zuerst im Verzeichnis /opt/node/bin nach ausführbaren Programmen. Wir können bestätigen, dass mit dem which Befehl:

:~/node$ which -a node || echo not found/opt/node/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)

Während die „Link“ -Lösung dauerhaft ist, sobald Sie den symbolischen Link in /usr/local/bin erstellt haben, ist die PATH Änderung nur in der aktuellen Shell wirksam. Ich überlasse es Ihnen, einige Nachforschungen anzustellen, wie Sie Änderungen an den PATH Permanenten vornehmen können. Als Hinweis hat es mit Ihrem „Profil“ zu tun. Wenn Sie die Lösung finden, zögern Sie nicht, dies mit den anderen Lesern zu teilen, indem Sie den Kommentarbereich unten verwenden!

E. So entfernen Sie diese neu installierte Software aus dem Quellcode

Da sich unsere speziell kompilierte NodeJS-Software vollständig im Verzeichnis /opt/node-v8.1.1 befindet, ist das Entfernen dieser Software nicht aufwendiger als das Entfernen dieses Verzeichnisses mit dem Befehl rm:

sudo rm -rf /opt/node-v8.1.1

ACHTUNG: sudo undrm -rf sind ein gefährlicher Cocktail! Überprüfen Sie Ihren Befehl immer zweimal, bevor Sie die Taste „Enter“ drücken. Sie werden keine Bestätigungsmeldung und keine Undelete haben, wenn Sie das falsche Verzeichnis entfernen …

Wenn Sie dann Ihre PATH geändert haben, müssen Sie diese Änderungen rückgängig machen, was überhaupt nicht kompliziert ist.

Und wenn Sie Links von /usr/local/bin erstellt haben, müssen Sie sie alle entfernen:

:~/node$ sudo find /usr/local/bin \ -type l \ -ilname "/opt/node/*" \ -print -delete/usr/local/bin/node

Warten Sie? Wo war die Abhängigkeitshölle?

Als letzten Kommentar, wenn Sie über das Kompilieren Ihrer eigenen benutzerdefinierten Software lesen, haben Sie vielleicht von der Abhängigkeitshölle gehört. Dies ist ein Spitzname für diese nervige Situation, in der Sie, bevor Sie eine Software erfolgreich kompilieren können, zuerst eine erforderliche Bibliothek kompilieren müssen, die wiederum eine andere Bibliothek erfordert, die möglicherweise nicht mit einer anderen Software kompatibel ist, die Sie bereits installiert haben.

Ein Teil der Aufgabe der Paketbetreuer Ihrer Distribution besteht darin, diese Abhängigkeit tatsächlich aufzulösen und sicherzustellen, dass die verschiedene Software Ihres Systems kompatible Bibliotheken verwendet und in der richtigen Reihenfolge installiert wird.

Für diesen Artikel habe ich mich absichtlich für die Installation von NodeJS entschieden, da es praktisch keine Abhängigkeiten gibt. Ich sagte „virtuell“, weil es tatsächlich Abhängigkeiten hat. Der Quellcode dieser Abhängigkeiten befindet sich jedoch im Quell-Repository des Projekts (im Unterverzeichnis node/deps ), sodass Sie sie vorher nicht manuell herunterladen und installieren müssen.