Como instalar executáveis

Question

Às vezes, encontro um software que não é oferecido em .deb ou .rpm , mas apenas como um executável.
Por exemplo, Código do Visual Studio , WebStorm ou Programa Espacial Kerbal .

Para esta pergunta, tomarei o código do Visual Studio como o ponto de referência.

O software é oferecido como um pacote zipado.
Ao descompactar, deixo uma pasta chamada VSCode-linux-x64 que contém um executável chamado Code .
Eu posso dar um duplo clique em Code ou apontar para ele com o meu terminal como /home/user/Downloads/VSCode-linux-x64/Code para executá-lo.
No entanto, gostaria de saber se existe uma maneira correta de instalar esses aplicativos.

O que eu quero alcançar é:

• um lugar onde eu posso colocar todos os aplicativos / softwares que são oferecido desta maneira (executáveis)
• suporte de terminal (isso significa exemplo: eu posso escrever vscode de qualquer pasta no meu terminal e executará automaticamente o código do Visual Studio.

Informação adicional:

• Desktop Environment: Gnome3
• SO: Debian

EDITAR:
Eu decidi dar @kba a resposta porque sua abordagem funciona melhor com a minha solução de backup e além disso. Ter script executando os binários dá a você a possibilidade de adicionar argumentos.
Mas para ser justo, a abordagem do @John WH Smith é tão boa quanto a do @kba.

    

Answer 1

Para chamar um programa pelo nome, os shells pesquisam os diretórios na variável de ambiente $PATH . No Debian, o $PATH padrão para seu usuário deve incluir /home/YOUR-USER-NAME/bin (ou seja, ~/bin ).

Primeiro, verifique se o diretório ~/bin existe 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 vscode na linha de comando ou em um lançador de comandos.

Observação: você também pode copiar binários para os diretórios $PATH , mas isso pode causar problemas se eles dependerem de caminhos relativos.

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

Atualização: Também refletindo os comentários de Thomas Dickey e A resposta de Faheem Mitha ao que costumo fazer para um software que vem como um tarball com um binário de nível superior e espera ser executado a partir daí:

Coloque-o em um local sadio (em ordem de conformidade com os padrões /opt , /usr/local ou uma pasta no seu diretório pessoal, por exemplo ~/build ) e crie um wrapper de script executável em um $PATH location (por exemplo, /usr/local/bin ou ~/bin ) que muda para esse local e executa o binário:

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

Como isso emula a mudança para esse diretório e a execução manual do binário, fica mais fácil depurar problemas como caminhos relativos inexistentes.

    

Answer 2

De acordo com TLDP , /opt pode ser um bom lugar para este tipo de software. Eu mesmo usei para armazenar algumas ferramentas relacionadas à impressora, e a versão "dinâmica" do Skype (como disse a kba, "suporte de terminal" pode ser obtida definindo a variável PATH de acordo).

Em geral, costumo usar /opt para "instalar" software proprietário empacotado como um executável, mas provavelmente é só eu. Além disso, eu costumo simplesmente evitar esse tipo de software, já que eu normalmente não tenho certeza sobre o que ele vai fazer quando eu o executar.

Outra razão pela qual escolhi /opt é porque normalmente é usada para código independente de terceiros, que não depende de nenhum arquivo fora de seu diretório /opt/'package' (e de outros diretórios opt , como /etc/opt ).

Under no circumstances are other package files to exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. [...] Generally, all data required to support a package on a system must be present within /opt/'package', including files intended to be copied into /etc/opt/'package' and /var/opt/'package' as well as reserved directories in /opt.

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

Any package to be installed here must locate its static files (ie. extra fonts, clipart, database files) in a separate /opt/'package' or /opt/'provider' directory tree (similar to the way in which Windows will install new software to its own directory tree C:\Windows\Progam Files\"Program Name"), where 'package' is a name that describes the software package and 'provider' is the provider's LANANA registered name.

Para mais informações, sugiro também que você leia essa outra pergunta sobre U & L , que trata das diferenças entre /opt e /usr/local . Eu pessoalmente evitaria /usr/local neste caso, especialmente se eu não fosse aquele que construiu o programa que estou instalando.

    

Answer 3

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

Sim, pacotes binários de distribuição do Linux como deb s e rpm s são normalmente gerados a partir da origem, mas não precisam ser. E é frequentemente (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 houver uma maneira de instalar corretamente o software, por exemplo, um destino de instalação em um makefile, que poderia ser usado com o mecanismo de empacotamento de distribuição. Caso contrário, isso pode envolver arquivos de mapeamento "manualmente" para os locais "certos", o que poderia ser muito trabalhoso. Embora criar um pacote desse tipo possa parecer uma coisa estranha, ele ainda teria um dos principais benefícios do gerenciamento de pacotes, ou seja, instalações e desinstalações limpas. E é claro que tal pacote nunca seria aceito em qualquer distribuição Linux que valesse o nome, mas essa não é sua pergunta.

    

Answer 4

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

O local habitual onde os binários instalados localmente 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) em seu $PATH , é possível executar o software digitando seu nome na linha de comando.

Normalmente, o software também deve ter uma página de manual (o software não documentado é ruim, certo?), que fica em /usr/local/man e pode ter alguns arquivos de suporte, como traduções em outros idiomas e plugins que podem estar em /usr/local/share ou /usr/local/lib , e assim por diante. Por esse motivo, o software que não é entregue como um pacote como .deb ou .rpm geralmente vem com um instalador que coloca tudo nos lugares certos. Quando você está instalando a partir do código-fonte, geralmente é make install .