So installieren Sie ausführbare Dateien

Manchmal stoße ich auf Software, die nicht .deboder .rpmnur als ausführbare Datei angeboten wird.
Zum Beispiel Visual Studio Code , WebStorm oder Kerbal Space Programm .

Für diese Frage nehme ich Visual Studio Code als Bezugspunkt.

Die Software wird als Zip-Paket angeboten.
Beim Entpacken verbleibt ein Ordner mit dem Namen VSCode-linux-x64einer ausführbaren Datei Code.
Ich kann Codemit meinem Terminal darauf doppelklicken oder darauf zeigen, um es /home/user/Downloads/VSCode-linux-x64/Codeauszuführen.
Ich würde jedoch gerne wissen, ob es einen geeigneten Weg gibt, diese Anwendungen zu installieren.

Was ich erreichen möchte, ist:

• einen Ort, an dem ich alle Anwendungen / Software, die auf diese Weise angeboten werden, ablegen kann (ausführbare Dateien)
• Terminalunterstützung (das heißt zum Beispiel: Ich kann vscodeaus jedem Ordner in meinem Terminal schreiben und es wird automatisch Visual Studio Code ausgeführt.

Zusätzliche Information:

• Desktop-Umgebung: Gnome3
• OS: Debian

EDIT:
Ich habe mich entschlossen, @kba die Antwort zu geben, da sein Ansatz mit meiner Backup-Lösung und darüber hinaus besser funktioniert. Wenn Sie die Binärdateien per Skript ausführen lassen, können Sie Argumente hinzufügen.
Aber um fair zu sein, @ John WH Smith Ansatz ist genauso gut wie @ kba's.

Um ein Programm nach seinem Namen aufzurufen, durchsuchen Shells die Verzeichnisse in der $PATHUmgebungsvariablen. In Debian sollte der Standard $PATHfür Ihren Benutzer /home/YOUR-USER-NAME/bin(dh ~/bin) enthalten.

Stellen Sie zunächst sicher, dass das Verzeichnis ~/binvorhanden ist, oder erstellen Sie es, wenn dies nicht der Fall ist:

mkdir -p ~/bin

Sie können Binärdateien mit diesem Verzeichnis verknüpfen, um es der Shell zur Verfügung zu stellen:

mkdir -p ~/bin
ln -s /home/user/Downloads/VSCode-linux-x64/Code ~/bin/vscode

Auf diese Weise können Sie in vscodeder Befehlszeile oder über einen Befehlsstarter ausgeführt werden.

Hinweis: Sie können auch Binärdateien in die $PATHVerzeichnisse kopieren , dies kann jedoch zu Problemen führen, wenn sie von relativen Pfaden abhängen.

Im Allgemeinen ist es jedoch immer vorzuziehen, Software mit den Mitteln des Betriebssystems (apt-get, deb packages) oder den Build-Tools eines Softwareprojekts ordnungsgemäß zu installieren. Dadurch wird sichergestellt, dass abhängige Pfade (wie Startskripte, Manpages, Konfigurationen usw.) korrekt eingerichtet werden.

Update: Unter Berücksichtigung von Thomas Dickeys Kommentaren und der Antwort von Faheem Mitha, die ich normalerweise für Software mache, die als Tarball mit einer Binärdatei der höchsten Ebene geliefert wird und von dort ausgeführt werden soll:

Legen Sie es in einer vernünftigen Position (in der Reihenfolge der Standards eingehalten /opt, /usr/localoder einen Ordner in Ihrem Home - Verzeichnis, zum Beispiel ~/build) , und erstellen Sie eine ausführbare Script - Wrapper in einem $PATHOrt (zB /usr/local/binoder ~/bin) , dass Änderungen an dieser Stelle und die binäre ausführt:

#/bin/sh
cd "$HOME/build/directory"
exec ./top-level-binary "$@"

Da dies das Wechseln in dieses Verzeichnis und das manuelle Ausführen der Binärdatei emuliert, ist es einfacher, Probleme wie nicht vorhandene relative Pfade zu debuggen.

Nach TLDP , /optkönnte ein guter Ort für diese Art von Software sein. Ich habe es selbst verwendet, um einige druckerbezogene Tools zu speichern, und die "dynamische" Version von Skype (wie kba sagte, kann "Terminal-Unterstützung" erreicht werden, indem die PATHVariable entsprechend eingestellt wird).

Im Allgemeinen neige ich dazu, /optproprietäre Software zu "installieren", die als ausführbare Datei gepackt ist, aber das bin wahrscheinlich nur ich. Außerdem vermeide ich diese Art von Software, da ich normalerweise keine Gewissheit habe, was es tun wird, wenn ich es einmal laufen lasse.

Ein weiterer Grund, warum ich mich entschieden habe, /optist, dass es normalerweise für unabhängigen Code von Drittanbietern gedacht ist, der sich nicht auf Dateien außerhalb seines /opt/'package'Verzeichnisses (und anderer optVerzeichnisse wie /etc/opt) stützt .

Unter keinen Umständen dürfen andere Paketdateien außerhalb der Hierarchien / opt, / var / opt und / etc / opt vorhanden sein, mit Ausnahme der Paketdateien, die sich an bestimmten Speicherorten in der Dateisystemstruktur befinden müssen, um ordnungsgemäß zu funktionieren. [...] Im Allgemeinen müssen alle Daten, die zur Unterstützung eines Pakets auf einem System erforderlich sind, in / opt / 'package' vorhanden sein, einschließlich der Dateien, die nach / etc / opt / 'package' und / var / opt / 'kopiert werden sollen. package 'sowie reservierte Verzeichnisse in / opt.

Ein Vorteil der Freigabe von Quellcode besteht darin, dass Benutzer den Kompilierungsprozess konfigurieren und benutzerdefinierte Bibliotheks- / Headerpfade basierend auf den Systemspezifikationen bereitstellen können. Wenn ein Entwickler beschließt, Code als ausführbare Datei freizugeben, geht dieser Vorteil verloren. IMHO darf der Entwickler zu diesem Zeitpunkt nicht mehr davon ausgehen, dass die Abhängigkeiten seines Programms verfügbar sind (weshalb alles zusammen mit der ausführbaren Datei gepackt werden sollte).

Jedes Paket, das hier installiert werden soll, muss seine statischen Dateien (dh zusätzliche Schriftarten, Cliparts, Datenbankdateien) in einem separaten Verzeichnisbaum (/ opt / 'package' oder / opt / 'provider') ablegen (ähnlich wie bei der Installation von Windows) neue Software in einen eigenen Verzeichnisbaum (C: \ Windows \ Programmdateien \ "Programmname"), wobei "Paket" ein Name ist, der das Softwarepaket beschreibt, und "Anbieter" der LANANA-registrierte Name des Anbieters ist.

Für weitere Informationen würde ich auch vorschlagen, diese andere U & L-Frage zu lesen , die sich mit den Unterschieden zwischen /optund befasst /usr/local. Ich würde es /usr/localin diesem Fall persönlich vermeiden , besonders wenn ich nicht derjenige bin, der das Programm erstellt, das ich installiere.

Es ist durchaus möglich und in der Tat recht einfach, ein Distributions-Binärpaket aus einem binären Zip-Archiv oder Tarball zu erstellen, wie in Ihrem Beispiel für Visual Studio-Code.

Ja, Linux-Distributions-Binärpakete wie debs und rpms werden normalerweise aus dem Quellcode generiert, müssen es aber nicht sein. Und es ist oft (wenn auch nicht immer) möglich, Dinge so zu arrangieren, dass das resultierende Distributions-Binärpaket Dinge an den "richtigen" Stellen installiert, um der Distributionsrichtlinie zu entsprechen.

Wenn es im Fall eines zufälligen proprietären Tarballs eine Möglichkeit gab, die Software ordnungsgemäß zu installieren, z. B. ein Installationsziel in einem Makefile, dann könnte dies mit der Distributionsverpackungsmaschine verwendet werden. Andernfalls müssen die Dateien möglicherweise "manuell" den "richtigen" Stellen zugeordnet werden, was eine Menge Arbeit bedeuten kann. Während das Erstellen eines solchen Pakets seltsam erscheinen mag, hätte es dennoch einen der Hauptvorteile der Paketverwaltung, nämlich eine saubere Installation und Deinstallation. Und natürlich würde ein solches Paket niemals in eine Linux-Distribution aufgenommen, die diesen Namen verdient, aber das ist nicht Ihre Frage.

Ich habe selten Software gesehen, die nur als ausführbare Binärdatei und sonst nichts geliefert wird, und ich wäre ehrlich gesagt ein bisschen misstrauisch. Wenn nichts anderes, würde ich zumindest ein README(mit Anleitung zur Installation) und ein LICENSEdazugehöriges erwarten . Davon abgesehen ...

Der übliche Ort, an dem lokal installierte Binärdateien, die nicht vom Paketmanager der Distribution verwaltet werden, aufbewahrt werden, ist /usr/local/bin. Sie können es dort ablegen, und da sich dieses Verzeichnis bereits in Ihrem befindet (oder befinden sollte), können $PATHSie die Software ausführen, indem Sie den Namen in die Befehlszeile eingeben.

Normalerweise sollte die Software auch eine Manpage haben (undokumentierte Software ist schlecht, oder?), Die eingebunden ist /usr/local/manund möglicherweise Unterstützungsdateien wie Übersetzungen in andere Sprachen und Plugins enthält, die eingebunden sind /usr/local/shareoder /usr/local/libund so weiter. Aus diesem Grund wird Software, die nicht als Paket geliefert wird, wie z. B. .deboder .rpmnormalerweise mit einem Installationsprogramm geliefert , das alles an den richtigen Stellen platziert. Wenn Sie von der Quelle installieren, ist dies normalerweise der Fall make install.