Come installare eseguibili

A volte mi imbatto in un software che non viene offerto in .debo .rpmma solo come eseguibile.
Ad esempio Visual Studio Code , WebStorm o Kerbal Space Programm .

Per questa domanda, prenderò il codice di Visual Studio come punto di riferimento.

Il software è offerto come pacchetto zippato.
Quando decompresso, mi rimane una cartella chiamata VSCode-linux-x64che contiene un eseguibile chiamato Code.
Posso fare doppio clic Codeo puntare su di esso con il mio terminale come /home/user/Downloads/VSCode-linux-x64/Codeeseguirlo.
Tuttavia, vorrei sapere se esiste un modo corretto per installare queste applicazioni.

Quello che voglio ottenere è:

• un posto dove posso mettere tutte le applicazioni / i software che sono offerti in questo modo (eseguibili)
• supporto terminale (ciò significa ad esempio: posso scrivere vscodeda qualsiasi cartella nel mio terminale e eseguirà automaticamente Visual Studio Code.

Informazioni addizionali:

• Ambiente desktop: Gnome3
• Sistema operativo: Debian

EDIT:
ho deciso di dare la risposta a @kba perché il suo approccio funziona meglio con la mia soluzione di backup e oltre a ciò. Avere script che esegue i binari ti dà la possibilità di aggiungere argomenti.
Ad essere onesti, l'approccio di @John WH Smith è buono quanto quello di @ kba.

Per chiamare un programma con il suo nome, le shell cercano le directory nella $PATHvariabile d'ambiente. In Debian, il valore predefinito $PATHper il tuo utente dovrebbe includere /home/YOUR-USER-NAME/bin(es ~/bin.).

Per prima cosa assicurati che la directory ~/binesista o creala se non:

mkdir -p ~/bin

È possibile collegare in modo binario i binari a quella directory per renderlo disponibile alla shell:

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

Ciò ti consentirà di eseguire vscodedalla riga di comando o da un comando di avvio.

Nota: è anche possibile copiare i file binari nelle $PATHdirectory ma ciò può causare problemi se dipendono da percorsi relativi.

In generale, tuttavia, è sempre preferibile installare correttamente il software utilizzando i mezzi forniti dal sistema operativo (apt-get, pacchetti deb) o gli strumenti di compilazione di un progetto software. Ciò assicurerà che i percorsi dipendenti (come script di avvio, pagine man, configurazioni ecc.) Siano impostati correttamente.

Aggiornamento: riflettendo anche i commenti di Thomas Dickey e la risposta di Faheem Mitha cosa faccio di solito per un software che viene fornito come un tarball con un binario di livello superiore e si aspetta che venga eseguito da lì:

Mettilo in una posizione sana (in ordine di conformità agli standard /opt, /usr/localo una cartella nella tua home directory, ad esempio ~/build) e crea un wrapper di script eseguibile in una $PATHposizione (ad esempio /usr/local/bino ~/bin) che cambi in quella posizione ed esegua il binario:

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

Poiché questo emula il passaggio a quella directory e l'esecuzione manuale del file binario, semplifica il debug di problemi come percorsi relativi inesistenti.

Secondo TLDP , /optpotrebbe essere un buon posto per questo tipo di software. L'ho usato io stesso per memorizzare alcuni strumenti relativi alla stampante e la versione "dinamica" di Skype (come diceva kba, "supporto terminale" può quindi essere ottenuto impostando la PATHvariabile di conseguenza).

Più in generale, tendo a usarlo /optper "installare" software proprietario impacchettato come eseguibile, ma probabilmente sono solo io. Inoltre, tendo semplicemente ad evitare questo tipo di software, dal momento che di solito non ho la certezza di cosa farà una volta eseguito.

Un altro motivo per cui ho scelto /optè perché di solito è pensato per codice indipendente di terze parti, che non si basa su alcun file al di fuori della sua /opt/'package'directory (e altre optdirectory come /etc/opt).

In nessun caso esistono altri file di pacchetto al di fuori delle gerarchie / opt, / var / opt e / etc / opt, ad eccezione di quei file di pacchetto che devono risiedere in posizioni specifiche all'interno dell'albero del filesystem per funzionare correttamente. [...] In generale, tutti i dati richiesti per supportare un pacchetto su un sistema devono essere presenti in / opt / 'package', inclusi i file che devono essere copiati in / etc / opt / 'package' e / var / opt / ' pacchetto "e directory riservate in / opt.

Uno dei vantaggi del rilascio del codice sorgente è che le persone possono configurare il processo di compilazione, fornendo percorsi di libreria / intestazioni personalizzati in base alle specifiche del proprio sistema. Quando uno sviluppatore decide di rilasciare il codice come eseguibile, tale vantaggio viene perso. IMHO, a questo punto, allo sviluppatore non è più consentito supporre che le dipendenze del suo programma saranno disponibili (motivo per cui tutto dovrebbe essere impacchettato insieme all'eseguibile).

Qualsiasi pacchetto da installare qui deve localizzare i suoi file statici (ad es. Font extra, clipart, file di database) in un albero di directory separato / opt / 'package' o / opt / 'provider' (simile al modo in cui Windows installerà nuovo software nel proprio albero di directory C: \ Windows \ File Progam \ "Nome programma"), dove "pacchetto" è un nome che descrive il pacchetto software e "fornitore" è il nome registrato LANANA del fornitore.

Per ulteriori informazioni, suggerirei anche di leggere quest'altra domanda U&L , che tratta delle differenze tra /opte /usr/local. Personalmente eviterei /usr/localin questo caso, soprattutto se non sono quello che ha creato il programma che sto installando.

È del tutto possibile, e in effetti abbastanza semplice, creare un pacchetto binario di distribuzione da un archivio zip binario o tarball, come nel tuo esempio di Visual Studio Code.

Sì, Linux pacchetti di distribuzione binari come debs e rpms sono solitamente generata dalla fonte, ma non dovrebbe essere così. Ed è spesso (anche se non sempre) possibile organizzare le cose in modo che il pacchetto binario di distribuzione risultante installi le cose nei luoghi "giusti" per conformarsi alla politica di distribuzione.

Nel caso di un tarball proprietario casuale, se esistesse un modo per installare correttamente il software, ad esempio un target di installazione in un makefile, questo potrebbe essere utilizzato con le macchine per l'imballaggio di distribuzione. Altrimenti, ciò potrebbe comportare la mappatura "manuale" dei file nei luoghi "giusti", il che potrebbe richiedere molto lavoro. Sebbene la creazione di un pacchetto del genere possa sembrare una cosa strana da fare, avrebbe comunque uno dei maggiori vantaggi della gestione dei pacchetti, vale a dire installazioni e disinstallazioni pulite. E ovviamente un tale pacchetto non verrebbe mai accettato in nessuna distribuzione Linux degna di questo nome, ma non è questa la tua domanda.

Raramente ho visto software distribuito come un eseguibile binario e nient'altro, e francamente ne sarei un po 'sospettoso. Se non altro mi aspetterei almeno un README(con le istruzioni per l'installazione) e un LICENSEper accompagnarlo. Detto ciò...

Il solito posto dove sono conservati i binari installati localmente non gestiti dal gestore dei pacchetti della distro è /usr/local/bin. Puoi metterlo lì, e poiché quella directory è (o dovrebbe essere) già nella tua $PATH, puoi eseguire il software digitandone il nome nella riga di comando.

Di solito il software dovrebbe anche avere una manpage (il software non documentato è male, giusto?) Che entra /usr/local/mane potrebbe avere alcuni file di supporto come traduzioni in altre lingue e plugin che potrebbero andare /usr/local/shareo o /usr/local/libcosì via. Per questo motivo, il software che non viene consegnato come un pacchetto come .debo di .rpmsolito viene fornito con un programma di installazione che mette tutto al posto giusto. Quando si esegue l'installazione dal sorgente, di solito è così make install.