So installieren Sie Software aus dem Quellcode … und entfernen sie anschließend

Kurz:Diese ausführliche Anleitung erklärt, wie man ein Programm aus dem Quellcode unter Linux installiert und die installierte Software aus dem Quellcode entfernt.

Eine der größten Stärken Ihrer Linux-Distribution ist ihr Paketmanager und das zugehörige Software-Repository. Damit verfügen Sie über alle notwendigen 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 alle Anwendungsfälle bewältigen. Sie können auch nicht die gesamte verfügbare Software paketieren. Es gibt also immer noch Situationen, in denen Sie neue Software selbst kompilieren und installieren müssen. Der bei weitem häufigste Grund, warum ich Software kompilieren muss, ist, wenn ich eine sehr spezifische Version ausführen oder den Quellcode durch die Verwendung einiger ausgefallener Kompilierungsoptionen modifizieren muss.

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

[irp posts=“13491″ name=“So installieren und entfernen Sie Software in Ubuntu“]

A. Software vom Quellcode unter Linux installieren

Und genau das werden wir hier tun. Nehmen wir für den Zweck 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

Nun, die Installation von NodeJs auf Ubuntu oder Debian ist ziemlich einfach, wenn Sie es mit dem Paketmanager tun. Aber machen wir es über den Quellcode.

Schritt 1:Quellcode von GitHub abrufen

Wie viele Open-Source-Projekte sind die Quellen von NodeJS auf GitHub zu finden: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 Aufbewahren 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 jedem beliebigen Zeitpunkt waren. Genauer gesagt, ich werde in der Lage sein, die Quellen so zu erhalten, wie sie waren, als die von mir gewünschte Version 8.1.1 veröffentlicht wurde. Auch wenn es seitdem viele Änderungen gegeben hat.

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

Nachdem Sie sich für das Tag „v8.1.1“ entschieden haben, wird die Seite aktualisiert, wobei die offensichtlichste Änderung darin besteht, dass das Tag jetzt als Teil der URL erscheint. Darüber hinaus werden Sie feststellen, dass auch das Dateiänderungsdatum unterschiedlich ist. Der Quellbaum, den Sie jetzt sehen, ist derjenige, der zum Zeitpunkt der Erstellung des v8.1.1-Tags existierte. In gewisser Weise kann man sich ein Versionskontrolltool wie Git als eine Zeitreisemaschine vorstellen, mit der man in einem Projektverlauf hin und her gehen kann.

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

wget https://github.com/nodejs/node/archive/v8.1.1.zip
unzip v8.1.1.zip
cd 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 zu verwenden Tool zum Herunterladen der Quellen. 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 system
sh$ sudo apt-get install git
# Make a shallow clone the NodeJS repository at v8.1.1
sh$ git clone --depth 1 \
              --branch v8.1.1 \
              https://github.com/nodejs/node
sh$ cd node/

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

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

sh$ ls
android-configure  BUILDING.md            common.gypi      doc            Makefile   src
AUTHORS            CHANGELOG.md           configure        GOVERNANCE.md  node.gyp   test
benchmark          CODE_OF_CONDUCT.md     CONTRIBUTING.md  lib            node.gypi  tools
BSDmakefile        COLLABORATOR_GUIDE.md  deps             LICENSE        README.md  vcbuild.bat

Schritt 2:Verstehen des Build-Systems des Programms

Wir sprechen normalerweise vom „Kompilieren der Quellen“, aber die Kompilierung ist nur eine der Phasen, die erforderlich sind, um eine funktionierende Software aus ihren Quellen zu erstellen. 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. Denn unterschiedliche Projekte oder Programmiersprachen können unterschiedliche Anforderungen haben. Oder wegen dem Geschmack 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. Alles in allem gibt es 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 eine gute Möglichkeit, 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 durch die Verwendung von zwei Tools: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, und sich schließlich mit den Besonderheiten der aktuellen Plattform befasst.

Ein wichtiger Teil einer typischen configure Die Aufgabe besteht darin, das Makefile zu erstellen . Das 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 das projektspezifische Makefile und führen Sie die erforderlichen Operationen aus, um Ihr Programm zu erstellen und zu installieren.

Aber wie immer in der Linux-Welt haben Sie immer noch etwas Nachsicht bei der Anpassung des Builds an Ihre speziellen Bedürfnisse.

./configure --help

Die configure -help Der Befehl zeigt Ihnen alle verfügbaren Konfigurationsoptionen. Auch dies ist sehr projektspezifisch. Und um ehrlich zu sein, ist es manchmal notwendig, sich in das Projekt einzuarbeiten, bevor man die Bedeutung jeder einzelnen Konfigurationsoption vollständig versteht.

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

[irp posts=“14419″ name=“8 Vim-Tipps und Tricks, die Sie zu einem Profi-Benutzer machen“]

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 das Standardinstallationsverzeichnis für Ihre neue Software /usr/local . Was ist eine gute Wahl, da laut FSH „Die /usr/local-Hierarchie 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.“

Der /usr/local Hierarchy repliziert irgendwie das Root-Verzeichnis, und Sie werden dort /usr/local/bin finden 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 von /usr/local Baum für die benutzerdefinierte Softwareinstallation ist, werden die Dateien für Ihre gesamte Software dort gemischt. Vor allem, nachdem Sie einige Software installiert haben, wird es schwierig sein, genau zu verfolgen, zu welcher Datei /usr/local/bin und /usr/local/lib gehört zu welcher Software. Das wird jedoch keine Probleme mit dem System verursachen. Immerhin /usr/bin ist ungefähr das gleiche Durcheinander. Aber das wird 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 in /opt zu installieren Unterbaum stattdessen. Um noch einmal die FHS zu zitieren:

_“/opt ist für die Installation zusätzlicher Anwendungssoftwarepakete reserviert.

Ein Paket, das in /opt installiert werden soll, muss seine statischen Dateien in einer separaten /opt/- oder /opt/-Verzeichnisstruktur finden, wobei ein Name ist, der das Softwarepaket beschreibt, und der registrierter LANANA-Name des Anbieters.“_

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

sh$ sudo mkdir /opt/node-v8.1.1
sh$ 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.1
sh$ 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“ nach dem make Befehl abgeschlossen wurde, würde bedeuten, dass während des Build-Prozesses ein Fehler aufgetreten ist. Da wir wegen des -j einen parallelen Build ausgeführt haben Option ist es nicht immer einfach, die Fehlermeldung abzurufen, wenn man bedenkt, wie viele Ausgaben das Build-System erzeugt.

Im Falle eines Problems starten Sie einfach make neu , aber ohne -j Möglichkeit diesmal. Und der Fehler sollte am Ende der Ausgabe erscheinen:

sh$ make

Schließlich, wenn 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 --version
v8.1.1

B. Was passiert, wenn bei der Installation vom Quellcode etwas schief geht?

Was ich oben erklärt habe, ist hauptsächlich das, was Sie auf der Seite „Bauanleitung“ eines gut dokumentierten Projekts sehen können. Da das Ziel dieses Artikels jedoch darin besteht, Ihnen das Kompilieren Ihrer ersten Software aus Quellen zu ermöglichen, lohnt es sich möglicherweise, sich die Zeit zu nehmen, einige allgemeine Probleme zu untersuchen. Also werde ich die ganze Prozedur wiederholen, aber diesmal von einem frischen und minimalen Debian 9.0- und CentOS 7.0-System, damit Sie die Fehler sehen können, auf die ich gestoßen bin, und wie ich sie gelöst habe.

Von Debian 9.0 „Stretch“

[email protected]:~$ 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:

[email protected]:~$ sudo apt-get install git

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

[email protected]:~/node$ sudo mkdir /opt/node-v8.1.1
[email protected]:~/node$ sudo ln -sT node-v8.1.1 /opt/node

Hier kein Problem.

[email protected]:~/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 wird, benötigen wir einen C++-Compiler. Hier werde ich `g++` installieren, den GNU C++ Compiler für diesen Zweck:

[email protected]:~/node$ sudo apt-get install g++
[email protected]:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok
[...]
ok

[email protected]:~/node$ make -j9 && echo ok
-bash: make: command not found

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

[email protected]:~/node$ sudo apt-get install make
[email protected]:~/node$ make -j9 && echo ok
[...]
ok

[email protected]:~/node$ sudo make install
[...]
[email protected]:~/node$ /opt/node/bin/node --version
v8.1.1

Erfolg!

Bitte beachten Sie:Ich habe die verschiedenen Tools einzeln 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 zu diesem Thema suchen oder andere Tutorials lesen, werden Sie feststellen, dass die meisten Distributionen „Metapakete“ haben, die als Dach dienen, um einige oder alle typischen Tools zu installieren, die zum Kompilieren einer Software verwendet werden. Auf Debian-basierten Systemen werden Sie zu diesem Zweck wahrscheinlich auf das Paket build-essentials stoßen. Und bei Red-Hat-basierten Distributionen sind das die „Entwicklungstools“ Gruppe.

Von CentOS 7.0

[[email protected] ~]$ 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:

[[email protected] ~]$ sudo yum install git

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

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

[[email protected] ~]$ cd node
[[email protected] 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 ahnen 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 tatsächlich 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

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

[[email protected] node]$ make -j9 && echo ok
[...]
ok

[[email protected] node]$ sudo make install && echo ok
[...]
ok

[[email protected] node]$ /opt/node/bin/node --version
v8.1.1

Erfolg. Wieder.

C. Änderungen an der vom Quellcode installierten Software vornehmen

Sie können Software aus der Quelle installieren, weil Sie eine sehr spezifische Version benötigen, die nicht in Ihrem Distributions-Repository verfügbar ist, oder weil Sie das Programm ändern möchten, um einen Fehler zu beheben oder eine Funktion hinzuzufügen. Schließlich dreht sich bei Open Source alles darum, Änderungen vorzunehmen. Daher werde ich diese Gelegenheit nutzen, um Ihnen einen Vorgeschmack auf die Möglichkeiten zu geben, die Ihnen jetzt zur Verfügung stehen, da Sie in der Lage sind, Ihre eigene Software zu kompilieren.

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[0], 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 ist etwa Zeile 3830 der Datei. Ändern Sie dann die Zeile mit printf stattdessen mit diesem übereinstimmen:

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

Gehen Sie dann zurück zu Ihrem 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.cc
index 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[0], 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 vor der Änderung war. 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 ok
[...]
ok

Diesmal ist der einzige Grund, warum es fehlschlagen könnte, dass Sie beim Ändern des Codes einen Tippfehler gemacht haben. Öffnen Sie in diesem Fall die node/src/node.cc erneut Datei 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:

[email protected]:~/node$ /opt/node/bin/node --version
v8.1.1 (compiled by myself)

Herzliche Glückwünsche! 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 klappt. Aber das ist gelinde gesagt ärgerlich. Es gibt eigentlich zwei gängige Möglichkeiten, das zu beheben.

Es gibt eigentlich zwei gängige Möglichkeiten, das lästige Problem der Angabe des absoluten Pfads 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 nur in den Verzeichnissen nach ihnen sucht, die durch die Umgebungsvariable PATH angegeben sind.

[email protected]:~/node$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Wenn Sie hier auf diesem Debian-System nicht explizit ein Verzeichnis 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 , wenn nicht gefunden … meldet die Shell einen Fehler „Befehl nicht gefunden“ .

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

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

Nur kopieren 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 zu finden, die zu /opt/node/ gehören (Es ist eine gängige Praxis für Software, ihre Ressourcendateien relativ zu ihrem eigenen Speicherort zu lokalisieren).

Der traditionelle Weg, dies zu tun, ist die Verwendung eines symbolischen Links:

[email protected]:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node
[email protected]:~/node$ which -a node || echo not found
/usr/local/bin/node
[email protected]:~/node$ node --version
v8.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 einzelnen vom Benutzer aufrufbaren Befehl einen symbolischen Link erstellen müssen. Wenn Sie beispielsweise mit NodeJS vertraut sind, kennen Sie den npm Begleitanwendung sollte ich von /usr/local/bin symbolisch verlinken zu. Aber das überlasse ich Ihnen als Übung.

Pfad ändern

Wenn Sie die vorherige Lösung ausprobiert haben, entfernen Sie zunächst den zuvor erstellten symbolischen Knoten-Link, um von einem gelöschten Zustand aus zu beginnen:

[email protected]:~/node$ sudo rm /usr/local/bin/node
[email protected]:~/node$ which -a node || echo not found
not found

Und jetzt ist hier der Zauberbefehl, um Ihren PATH zu ändern :

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

Einfach gesagt, ich habe den Inhalt des PATH ersetzt Umgebungsvariable durch ihren vorherigen Inhalt, aber mit dem Präfix /opt/node/bin . Also, wie Sie sich jetzt vorstellen können, wird die Shell zuerst in /opt/node/bin schauen Verzeichnis für ausführbare Programme. Wir können das mit dem which bestätigen Befehl:

[email protected]:~/node$ which -a node || echo not found
/opt/node/bin/node
[email protected]:~/node$ node --version
v8.1.1 (compiled by myself)

Wohingegen die „Link“-Lösung dauerhaft ist, sobald Sie den symbolischen Link in /usr/local/bin erstellt haben , der PATH Die Änderung ist nur in der aktuellen Shell wirksam. Ich überlasse es Ihnen, etwas zu recherchieren, wie Sie Änderungen im PATH vornehmen können bleibende Sachen. Als Hinweis, es hat mit Ihrem „Profil“ zu tun. Wenn Sie die Lösung finden, zögern Sie nicht, sie 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 individuell kompilierte NodeJS-Software vollständig in /opt/node-v8.1.1 befindet Verzeichnis, erfordert das Entfernen dieser Software nicht mehr Aufwand als die Verwendung des rm-Befehls, um dieses Verzeichnis zu entfernen:

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

ACHTUNG: sudo und rm -rf sind ein gefährlicher Cocktail! Überprüfen Sie Ihren Befehl immer zweimal, bevor Sie die Eingabetaste drücken. Sie erhalten keine Bestätigungsmeldung und kein Wiederherstellen, wenn Sie das falsche Verzeichnis entfernen…

Dann, wenn Sie Ihren 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 Sie müssen sie alle entfernen:

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

Warte? Wo war die Abhängigkeitshölle?

Als letzte Bemerkung:Wenn Sie über das Kompilieren Ihrer eigenen benutzerdefinierten Software gelesen haben, haben Sie vielleicht schon von der Abhängigkeitshölle gehört. Dies ist ein Spitzname für die ärgerliche Situation, in der Sie, bevor Sie eine Software erfolgreich kompilieren können, zuerst eine vorausgesetzte Bibliothek kompilieren müssen, die wiederum eine andere Bibliothek erfordert, die wiederum mit einer anderen Software, die Sie bereits haben, inkompatibel sein könnte installiert.

Ein Teil der Aufgabe der Paketbetreuer Ihrer Distribution besteht darin, diese Abhängigkeitshölle tatsächlich zu lö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 bewusst für die Installation von NodeJS entschieden, da es praktisch keine Abhängigkeiten hat. Ich sagte „virtuell“, weil es tatsächlich hat Abhängigkeiten. Aber der Quellcode dieser Abhängigkeiten ist im Quell-Repository des Projekts vorhanden (in node/deps Unterverzeichnis), sodass Sie sie nicht vorher manuell herunterladen und installieren müssen.

Aber wenn Sie daran interessiert sind, mehr über dieses Problem zu erfahren und zu lernen, wie man damit umgeht, lassen Sie es mich wissen, indem Sie den Kommentarbereich unten verwenden:Das wäre ein großartiges Thema für einen fortgeschritteneren Artikel!