Cómo instalar ejecutables

A veces me encuentro con software que no se ofrece .debo .rpmsolo como un ejecutable.
Por ejemplo, Visual Studio Code , WebStorm o Kerbal Space Programm .

Para esta pregunta, tomaré Visual Studio Code como punto de referencia.

El software se ofrece como un paquete comprimido.
Al descomprimir, me queda una carpeta llamada VSCode-linux-x64que contiene un ejecutable llamado Code.
Puedo hacer doble clic Codeo señalarlo con mi terminal /home/user/Downloads/VSCode-linux-x64/Codepara ejecutarlo.
Sin embargo, me gustaría saber si hay una manera adecuada de instalar estas aplicaciones.

Lo que quiero lograr es:

• un lugar donde puedo poner todas las aplicaciones / softwares que se ofrecen de esta manera (ejecutables)
• soporte de terminal (eso significa, por ejemplo: puedo escribir vscodedesde cualquier carpeta en mi terminal y ejecutará automáticamente Visual Studio Code.

Información adicional:

• Entorno de escritorio: Gnome3
• OS: Debian

EDITAR:
decidí darle a @kba la respuesta porque su enfoque funciona mejor con mi solución de respaldo y, además, eso. Tener un script que ejecute los binarios le da la posibilidad de agregar argumentos.
Pero para ser justos, el enfoque de @ John WH Smith es tan bueno como el de @ kba.

Para llamar a un programa por su nombre, los shells buscan los directorios en la $PATHvariable de entorno. En Debian, el valor predeterminado $PATHpara su usuario debe incluir /home/YOUR-USER-NAME/bin(es decir ~/bin).

Primero asegúrese de que el directorio ~/binexiste o créelo si no es así:

mkdir -p ~/bin

Puede vincular binarios a ese directorio para que esté disponible para el shell:

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

Eso le permitirá ejecutar vscodeen la línea de comandos o desde un iniciador de comandos.

Nota: También puede copiar binarios en los $PATHdirectorios, pero eso puede causar problemas si dependen de rutas relativas.

Sin embargo, en general, siempre es preferible instalar correctamente el software utilizando los medios provistos por el sistema operativo (apt-get, deb packages) o las herramientas de compilación de un proyecto de software. Esto asegurará que las rutas dependientes (como scripts de inicio, páginas de manual, configuraciones, etc.) estén configuradas correctamente.

Actualización: reflejando también los comentarios de Thomas Dickey y la respuesta de Faheem Mitha, lo que suelo hacer para el software que viene como un tarball con un binario de nivel superior y espera ejecutarse desde allí:

Póngalo en una ubicación correcta (en orden de cumplimiento de estándares /opt, /usr/localo en una carpeta en su directorio de inicio, por ejemplo ~/build) y cree un contenedor de script ejecutable en una $PATHubicación (por ejemplo, /usr/local/bino ~/bin) que cambie a esa ubicación y ejecute el binario:

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

Dado que esto emula cambiar a ese directorio y ejecutar el binario manualmente, facilita la depuración de problemas como rutas relativas no existentes.

Según TLDP , /optpodría ser un buen lugar para este tipo de software. Lo he usado yo mismo para almacenar algunas herramientas relacionadas con la impresora, y la versión "dinámica" de Skype (como dijo kba, el "soporte de terminal" se puede lograr configurando la PATHvariable en consecuencia).

De manera más general, tiendo a usar /optpara "instalar" software propietario empaquetado como ejecutable, pero probablemente solo soy yo. Además, tiendo a evitar este tipo de software, ya que generalmente no tengo certeza de lo que hará una vez que lo ejecute.

Otra razón por la que elegí /optes porque generalmente está destinado a un código independiente de terceros, que no se basa en ningún archivo fuera de su /opt/'package'directorio (y otros optdirectorios como /etc/opt).

Bajo ninguna circunstancia deben existir otros archivos de paquete fuera de las jerarquías / opt, / var / opt y / etc / opt, excepto aquellos archivos de paquete que deben residir en ubicaciones específicas dentro del árbol del sistema de archivos para funcionar correctamente. [...] En general, todos los datos necesarios para admitir un paquete en un sistema deben estar presentes en / opt / 'package', incluidos los archivos destinados a copiarse en / etc / opt / 'package' y / var / opt / ' paquete 'así como directorios reservados en / opt.

Una ventaja de liberar el código fuente es que las personas pueden configurar el proceso de compilación, proporcionando rutas personalizadas de biblioteca / encabezados según los detalles de su sistema. Cuando un desarrollador decide lanzar código como ejecutable, esa ventaja se pierde. En mi humilde opinión, en este momento, el desarrollador ya no puede asumir que las dependencias de su programa estarán disponibles (por lo que todo debería estar empaquetado junto con el ejecutable).

Cualquier paquete que se instale aquí debe ubicar sus archivos estáticos (es decir, fuentes adicionales, imágenes prediseñadas, archivos de base de datos) en un árbol de directorio / opt / 'package' u / opt / 'provider' (similar a la forma en que se instalará Windows nuevo software en su propio árbol de directorios C: \ Windows \ Archivos de programa \ "Nombre del programa"), donde 'paquete' es un nombre que describe el paquete de software y 'proveedor' es el nombre registrado de LANANA del proveedor.

Para obtener más información, también sugeriría leer esta otra pregunta de U&L , que trata las diferencias entre /opty /usr/local. Yo personalmente evitaría /usr/localen este caso, especialmente si no soy yo quien creó el programa que estoy instalando.

Es completamente posible, y de hecho bastante fácil, crear un paquete binario de distribución a partir de un archivo zip binario o tarball, como en su ejemplo de Visual Studio Code.

Sí, los paquetes binarios de distribución de Linux como debsys rpmse generan habitualmente desde la fuente, pero no tienen que serlo. Y a menudo (aunque no siempre) es posible organizar las cosas para que el paquete binario de distribución resultante instale las cosas en los lugares "correctos" para cumplir con la política de distribución.

En el caso de un tarball propietario aleatorio, si hubiera una manera de instalar correctamente el software, por ejemplo, un objetivo de instalación en un archivo MAKE, entonces eso podría usarse con la maquinaria de empaquetado de distribución. De lo contrario, esto podría involucrar el mapeo "manual" de archivos a los lugares "correctos", lo que podría ser mucho trabajo. Si bien crear un paquete de este tipo puede parecer algo extraño, aún tendría uno de los principales beneficios de la administración de paquetes, a saber, instalaciones y desinstalaciones limpias. Y, por supuesto, dicho paquete nunca sería aceptado en ninguna distribución de Linux que valga la pena, pero esa no es su pregunta.

Raramente he visto software que se entrega como un ejecutable binario y nada más, y francamente sospecharía un poco de él. Por lo menos, al menos esperaría un README(con instrucciones para instalarlo) y un LICENSEpara acompañarlo. Habiendo dicho eso...

El lugar habitual donde se guardan los archivos binarios instalados localmente no administrados por el administrador de paquetes de la distribución es /usr/local/bin. Puede ponerlo allí, y dado que ese directorio ya está (o debería estar) en su $PATH, puede ejecutar el software escribiendo su nombre en la línea de comando.

Por lo general, el software también debe tener una página de manual (el software no documentado es malo, ¿verdad?) Que entra /usr/local/many puede tener algunos archivos de soporte, como traducciones a otros idiomas y complementos que pueden entrar /usr/local/shareo /usr/local/lib, y así sucesivamente. Por esta razón, el software que no se entrega como un paquete, .debo que por lo .rpmgeneral viene con un instalador que coloca todo en los lugares correctos. Cuando está instalando desde la fuente, eso suele ser make install.