Comment installer les exécutables

Je rencontre parfois des logiciels qui ne sont pas proposés dans .debou .rpmuniquement comme exécutables.
Par exemple, Visual Studio Code , WebStorm ou Kerbal Space Programm .

Pour cette question, je prendrai Visual Studio Code comme point de référence.

Le logiciel est proposé sous forme de package zippé.
Lors de la décompression, je me retrouve avec un dossier appelé VSCode-linux-x64qui contient un exécutable nommé Code.
Je peux double-cliquer Codeou pointer dessus avec mon terminal comme /home/user/Downloads/VSCode-linux-x64/Codepour l'exécuter.
Cependant, je voudrais savoir s'il existe un moyen approprié d'installer ces applications.

Ce que je veux réaliser, c'est:

• un seul endroit où je peux mettre toutes les applications / logiciels qui sont offerts de cette manière (exécutables)
• prise en charge du terminal (cela signifie par exemple: je peux écrire à vscodepartir de n'importe quel dossier de mon terminal et il exécutera automatiquement Visual Studio Code.

Information additionnelle:

• Environnement de bureau: Gnome3
• OS: Debian

EDIT:
J'ai décidé de donner la réponse à @kba parce que son approche fonctionne mieux avec ma solution de sauvegarde et en plus de cela. Avoir un script exécutant les binaires vous donne la possibilité d'ajouter des arguments.
Mais pour être juste, l'approche @John WH Smith est aussi bonne que celle de @ kba.

Pour appeler un programme par son nom, les shells recherchent les répertoires dans la $PATHvariable d'environnement. Dans Debian, la valeur $PATHpar défaut pour votre utilisateur devrait inclure /home/YOUR-USER-NAME/bin(ie ~/bin).

Assurez-vous d'abord que le répertoire ~/binexiste ou créez-le si ce n'est pas le cas:

mkdir -p ~/bin

Vous pouvez créer un lien symbolique entre les fichiers binaires et le répertoire pour le rendre accessible au shell:

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

Cela vous permettra d'exécuter vscodesur la ligne de commande ou à partir d'un lanceur de commandes.

Remarque: Vous pouvez également copier des fichiers binaires dans les $PATHrépertoires mais cela peut poser des problèmes s'ils dépendent de chemins relatifs.

En général, cependant, il est toujours préférable d'installer correctement le logiciel en utilisant les moyens fournis par le système d'exploitation (apt-get, paquets deb) ou les outils de construction d'un projet logiciel. Cela garantira que les chemins dépendants (comme les scripts de démarrage, les pages de manuel, les configurations, etc.) sont correctement configurés.

Mise à jour: reflétant également les commentaires de Thomas Dickey et la réponse de Faheem Mitha ce que je fais habituellement pour les logiciels qui se présentent sous la forme d'une archive tar avec un binaire de haut niveau et s'attendent à être exécutés à partir de là:

Mettez - le dans un endroit sain d' esprit (pour des normes de conformité /opt, /usr/localou un dossier dans votre répertoire personnel, par exemple ~/build) et créer une enveloppe de script exécutable dans un $PATHemplacement (par exemple , /usr/local/binou ~/bin) que des modifications à cet endroit et exécute le binaire:

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

Comme cela émule la modification de ce répertoire et l'exécution manuelle du binaire, il est plus facile de déboguer des problèmes tels que des chemins relatifs inexistants.

Selon TLDP , /optpourrait être un bon endroit pour ce type de logiciel. Je l'ai utilisé moi-même pour stocker des outils liés à l'imprimante, et la version "dynamique" de Skype (comme l'a dit kba, le "support du terminal" peut alors être obtenu en définissant la PATHvariable en conséquence).

Plus généralement, j'ai tendance à /opt«installer» des logiciels propriétaires emballés comme un exécutable, mais c'est probablement juste moi. En outre, j'ai tendance à simplement éviter ce type de logiciel, car je n'ai généralement aucune certitude quant à ce qu'il fera une fois que je l'aurai exécuté.

Une autre raison pour laquelle j'ai choisi /optest parce qu'il est généralement destiné au code tiers indépendant, qui ne dépend d'aucun fichier en dehors de son /opt/'package'répertoire (et d'autres optrépertoires tels que /etc/opt).

En aucun cas, d'autres fichiers de package ne doivent exister en dehors des hiérarchies / opt, / var / opt et / etc / opt, à l'exception des fichiers de package qui doivent résider à des emplacements spécifiques dans l'arborescence du système de fichiers pour fonctionner correctement. [...] Généralement, toutes les données nécessaires à la prise en charge d'un package sur un système doivent être présentes dans / opt / 'package', y compris les fichiers destinés à être copiés dans / etc / opt / 'package' et / var / opt / ' package 'ainsi que des répertoires réservés dans / opt.

L'un des avantages de la publication du code source est que les utilisateurs peuvent configurer le processus de compilation, en fournissant des chemins de bibliothèque / en-têtes personnalisés en fonction des spécificités de leur système. Lorsqu'un développeur décide de publier du code en tant qu'exécutable, cet avantage est perdu. À mon humble avis, à ce stade, le développeur n'est plus autorisé à supposer que les dépendances de son programme seront disponibles (c'est pourquoi tout devrait être empaqueté avec l'exécutable).

Tout package à installer ici doit localiser ses fichiers statiques (c'est-à-dire des polices supplémentaires, des cliparts, des fichiers de base de données) dans une arborescence de répertoires / opt / 'package' ou / opt / 'provider' distincte (similaire à la façon dont Windows installera nouveau logiciel dans sa propre arborescence de répertoires C: \ Windows \ Progam Files \ "Program Name"), où 'package' est un nom qui décrit le package logiciel et 'provider' est le nom enregistré LANANA du fournisseur.

Pour plus d'informations, je suggère également de lire cette autre question U&L , qui traite des différences entre /optet /usr/local. J'éviterais personnellement /usr/localdans ce cas, surtout si ce n'est pas moi qui ai construit le programme que j'installe.

Il est tout à fait possible, et en fait assez simple, de créer un package binaire de distribution à partir d'une archive zip binaire ou tarball, comme dans votre exemple de code Visual Studio.

Oui, les packages binaires de distribution Linux tels que debs et rpms sont généralement générés à partir de la source, mais ils ne doivent pas l'être. Et il est souvent (mais pas toujours) possible d'arranger les choses pour que le package binaire de distribution qui en résulte installe les choses aux «bons» endroits pour se conformer à la politique de distribution.

Dans le cas d'un tarball propriétaire aléatoire, s'il y avait un moyen d'installer correctement le logiciel, par exemple une cible d'installation dans un makefile, alors cela pourrait être utilisé avec les machines d'emballage de distribution. Sinon, cela pourrait impliquer de mapper «manuellement» les fichiers aux «bons» endroits, ce qui pourrait représenter beaucoup de travail. Bien que la création d'un tel package puisse sembler une chose étrange à faire, elle aurait toujours l'un des principaux avantages de la gestion des packages, à savoir des installations et des désinstallations propres. Et bien sûr, un tel package ne serait jamais accepté dans aucune distribution Linux digne de ce nom, mais ce n'est pas votre question.

J'ai rarement vu un logiciel livré comme un exécutable binaire et rien d'autre, et je serais franchement un peu méfiant. Si rien d'autre, je m'attendrais au moins à un README(avec des instructions pour l'installer) et à un LICENSEpour l'accompagner. Cela étant dit...

L'endroit habituel où les binaires installés localement et non gérés par le gestionnaire de paquets de la distribution sont conservés est /usr/local/bin. Vous pouvez le mettre là, et puisque ce répertoire est (ou devrait être) déjà dans votre, $PATHvous pouvez exécuter le logiciel en tapant son nom sur la ligne de commande.

Habituellement, le logiciel devrait également avoir une page de manuel (un logiciel non documenté est mauvais, non?) Qui entre /usr/local/manet pourrait avoir des fichiers de support tels que des traductions dans d'autres langues et des plugins qui pourraient entrer dans /usr/local/shareou /usr/local/lib, et ainsi de suite. Pour cette raison, les logiciels qui ne sont pas fournis sous forme de package tels que .debou sont .rpmgénéralement fournis avec un programme d'installation qui place tout au bon endroit. Lorsque vous installez à partir de la source, c'est généralement le cas make install.