Como instalar executáveis

Às vezes, encontro softwares que não são oferecidos .debou são .rpmapenas executáveis.
Por exemplo, Visual Studio Code , WebStorm ou Kerbal Space Programm .

Para esta pergunta, tomarei o Visual Studio Code como ponto de referência.

O software é oferecido como um pacote compactado.
Ao descompactar, fico com uma pasta chamada VSCode-linux-x64que contém um executável chamado Code.
Posso clicar duas vezes Codeou apontar para ele com o meu terminal /home/user/Downloads/VSCode-linux-x64/Codepara executá-lo.
No entanto, gostaria de saber se existe uma maneira adequada de instalar esses aplicativos.

O que eu quero alcançar é:

• um lugar onde eu posso colocar todos os aplicativos / softwares oferecidos dessa maneira (executáveis)
• suporte ao terminal (que significa, por exemplo: eu posso escrever vscodeem qualquer pasta do meu terminal e ele executará automaticamente o Visual Studio Code.

Informação adicional:

• Ambiente de trabalho: Gnome3
• SO: Debian

EDIT:
Decidi dar a resposta ao @kba porque sua abordagem funciona melhor com a minha solução de backup e além disso. Ter um script executando os binários oferece a possibilidade de adicionar argumentos.
Mas, para ser justo, a abordagem de John WH Smith é tão boa quanto a da @ kba.

Para chamar um programa por seu nome, os shells pesquisam os diretórios na $PATHvariável de ambiente. No Debian, o padrão $PATHpara o seu usuário deve incluir /home/YOUR-USER-NAME/bin(ie ~/bin).

Primeiro verifique se o diretório ~/binexiste ou crie-o se não existir:

mkdir -p ~/bin

Você pode vincular binários a esse diretório para torná-lo disponível para o shell:

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

Isso permitirá que você execute vscodena linha de comandos ou em um iniciador de comandos.

Nota: Você também pode copiar binários para os $PATHdiretórios, mas isso pode causar problemas se eles dependerem de caminhos relativos.

Em geral, porém, é sempre preferível instalar o software corretamente usando os meios fornecidos pelo sistema operacional (pacotes apt-get, deb) ou as ferramentas de construção de um projeto de software. Isso garantirá que os caminhos dependentes (como scripts de início, páginas de manual, configurações etc.) sejam configurados corretamente.

Atualização: também refletindo os comentários de Thomas Dickey e a resposta de Faheem Mitha, o que eu costumo fazer com softwares que vêm como tarball com um binário de nível superior e esperam ser executados a partir daí:

Coloque-o em um local sã (em ordem de padrões de conformidade /opt, /usr/localou uma pasta em seu diretório pessoal, por exemplo ~/build) e criar um wrapper de script executável em um $PATHlocal (por exemplo, /usr/local/binou ~/bin) que as mudanças para esse local e executa o binário:

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

Como isso emula a alteração para esse diretório e a execução manual do binário, facilita a depuração de problemas como caminhos relativos inexistentes.

Segundo o TLDP , /optpode ser um bom lugar para esse tipo de software. Eu mesmo usei para armazenar algumas ferramentas relacionadas à impressora, e a versão "dinâmica" do Skype (como disse o kba, "suporte ao terminal" pode ser alcançado configurando a PATHvariável de acordo).

De maneira mais geral, costumo usar /optpara "instalar" o software proprietário compactado como um executável, mas isso provavelmente é só comigo. Além disso, eu tendem a simplesmente evitar esse tipo de software, já que geralmente não tenho certeza do que ele fará quando o rodar.

Outro motivo pelo qual eu escolhi /opté porque geralmente é para código independente de terceiros, que não depende de nenhum arquivo fora do /opt/'package'diretório (e de outros optdiretórios, como /etc/opt).

Sob nenhuma circunstância existem outros arquivos de pacote fora das hierarquias / opt, / var / opt e / etc / opt, exceto para os arquivos de pacote que devem residir em locais específicos na árvore do sistema de arquivos para funcionar corretamente. [...] Geralmente, todos os dados necessários para suportar um pacote em um sistema devem estar presentes em / opt / 'package', incluindo arquivos destinados a serem copiados em / etc / opt / 'package' e / var / opt / ' package ', bem como diretórios reservados em / opt.

Uma vantagem da liberação do código-fonte é que as pessoas configuram o processo de compilação, fornecendo caminhos de biblioteca / cabeçalhos personalizados com base nas especificidades do sistema. Quando um desenvolvedor decide liberar o código como um executável, essa vantagem é perdida. IMHO, neste ponto, o desenvolvedor não está mais autorizado a assumir que as dependências de seu programa estarão disponíveis (é por isso que tudo deve ser empacotado juntamente com o executável).

Qualquer pacote a ser instalado aqui deve localizar seus arquivos estáticos (por exemplo, fontes extras, clipart, arquivos de banco de dados) em uma árvore de diretórios / opt / 'package' ou / opt / 'provider' separada (semelhante à maneira como o Windows instalará novo software em sua própria árvore de diretórios C: \ Windows \ Arquivos de Progam \ "Nome do Programa"), em que 'pacote' é um nome que descreve o pacote de software e 'provedor' é o nome registrado da LANANA do provedor.

Para obter mais informações, eu também sugeriria a leitura dessa outra questão de U&L , que lida com as diferenças entre /opte /usr/local. Eu evitaria pessoalmente /usr/localnesse caso, especialmente se não sou eu quem criou o programa que estou instalando.

É inteiramente possível, e de fato bastante fácil, criar um pacote binário de distribuição a partir de um arquivo zip ou tarball binário, como no seu exemplo do Visual Studio Code.

Sim, pacotes binários de distribuição do Linux como debs e rpms são normalmente gerados a partir da fonte, mas não precisam ser. E muitas vezes (embora nem sempre) é possível organizar as coisas para que o pacote binário de distribuição resultante instale as coisas nos locais "certos" para estar em conformidade com a política de distribuição.

No caso de um tarball proprietário aleatório, se houvesse uma maneira de instalar corretamente o software, por exemplo, um destino de instalação em um makefile, isso poderia ser usado com a maquinaria de embalagem de distribuição. Caso contrário, isso pode envolver o mapeamento "manual" dos arquivos para os locais "certos", o que pode dar muito trabalho. Embora a criação de um pacote possa parecer algo estranho, ele ainda possui um dos principais benefícios do gerenciamento de pacotes, a saber: instalações e desinstalações limpas. E é claro que esse pacote nunca seria aceito em nenhuma distribuição Linux que valha o nome, mas essa não é a sua pergunta.

Eu raramente vi um software que é entregue apenas como um executável binário e nada mais, e sinceramente suspeitava disso. Se nada mais, pelo menos, eu esperaria um README(com instruções para instalá-lo) e um LICENSEpara acompanhá-lo. Dito isto ...

O local usual em que os binários instalados localmente e não gerenciados pelo gerenciador de pacotes da distribuição são mantidos /usr/local/bin. Você pode colocá-lo lá e, como esse diretório já está (ou deveria estar) no seu, $PATHvocê pode executar o software digitando seu nome na linha de comando.

Normalmente, o software também deve ter uma página de manual (software não documentado é ruim, certo?) Que entra /usr/local/mane pode ter alguns arquivos de suporte, como traduções para outros idiomas e plugins que podem entrar /usr/local/shareou /usr/local/libassim por diante. Por esta razão, o software que não é fornecido como um pacote como .debou .rpmnormalmente vem com um instalador que coloca tudo nos lugares certos. Quando você está instalando a partir do código-fonte, normalmente é make install.