Yürütülebilir dosyalar nasıl yüklenir

Bazen sunulan .debveya .rpmsadece yürütülebilir olarak sunulan bir yazılımla karşılaşıyorum .
Örneğin, Visual Studio Code , WebStorm veya Kerbal Space Programm .

Bu soru için, başvuru noktası olarak Visual Studio Code'u alacağım.

Yazılım sıkıştırılmış bir paket olarak sunulmaktadır.
Sıkıştırırken, adlı VSCode-linux-x64bir yürütülebilir dosya içeren bir klasör bıraktım Code. Terminali çalıştırmak için
çift ​​tıklayabilir Codeveya işaret edebilirim /home/user/Downloads/VSCode-linux-x64/Code.
Ancak, bu uygulamaları yüklemek için uygun bir yol olup olmadığını bilmek istiyorum.

Ne elde etmek istiyorum:

• bu şekilde sunulan tüm uygulamaları / yazılımları koyabileceğim tek bir yer (yürütülebilir dosyalar)
• terminal desteği (örneğin: vscodeTerminalimdeki herhangi bir klasörden yazabilirim ve otomatik olarak Visual Studio Code'u çalıştıracaktır).

İlave bilgi:

• Masaüstü Ortamı: Gnome3
• İşletim Sistemi: Debian

DÜZENLEME:
@kba'ya cevap vermeye karar verdim çünkü yaklaşımı yedekleme çözümümle daha iyi çalışıyor ve bunun yanında. Komut dosyalarını ikili dosyaları yürütmek size argüman ekleme imkanı verir.
Ama adil olmak gerekirse, @John WH Smith yaklaşımı @ kba'nınki kadar iyidir.

Bir programı adına göre çağırmak için, kabuklar $PATHortam değişkenindeki dizinlerde arama yapar . Debian'da, $PATHkullanıcınızın varsayılan değeri /home/YOUR-USER-NAME/bin(ie ~/bin) içermelidir .

Öncelikle dizinin ~/binvar olduğundan emin olun veya yoksa dizini oluşturun:

mkdir -p ~/bin

Kabuğun kullanımına açmak için ikili dosyaları bu dizine bağlayabilirsiniz:

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

Bu vscode, komut satırında veya bir komut başlatıcıdan çalışmanıza izin verir .

Not: İkilileri $PATHdizinlere de kopyalayabilirsiniz, ancak göreli yollara bağlıysa sorunlara neden olabilir.

Bununla birlikte, genel olarak, işletim sistemi (apt-get, deb paketleri) veya bir yazılım projesinin derleme araçlarını kullanarak yazılımları düzgün bir şekilde kurmak her zaman tercih edilir. Bu, bağımlı yolların (başlangıç ​​komut dosyaları, kılavuz sayfaları, yapılandırmalar vb.) Doğru şekilde ayarlanmasını sağlayacaktır.

Güncelleme: Ayrıca Thomas Dickey'nin yorumlarını ve Faheem Mitha'nın üst düzey bir ikili ile bir tarball olarak gelen ve oradan çalıştırılmayı beklediği yazılım için ne yaptığımı cevaplıyor :

(Standartlara uygunluk sırasına göre aklı başında bir konumda koy /opt, /usr/localveya ana dizinine, örneğin bir klasöre ~/build) ve bir de yürütülebilir bir komut sarmalayıcı oluşturmak $PATH(örneğin konum /usr/local/binveya ~/binbu konuma değişiklikler ve ikili yürüten):

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

Bu, bu dizine geçmeyi ve ikili dosyayı el ile yürütmeyi öyküntüğünden, var olmayan göreli yollar gibi sorunların hata ayıklanmasını kolaylaştırır.

TLDP'ye göre , /optbu tür yazılımlar için iyi bir yer olabilir. Kendimi yazıcıyla ilgili bazı araçları saklamak için kullandım ve Skype'ın "dinamik" sürümü (kba'nın dediği gibi, "terminal desteği" daha sonra PATHdeğişken buna göre ayarlanarak elde edilebilir ).

Daha genel /optolarak, çalıştırılabilir olarak paketlenmiş tescilli yazılımı "yüklemek" eğilimindeyim , ama muhtemelen sadece ben. Ayrıca, bu tür bir yazılımdan kaçınma eğilimindeyim, çünkü genellikle çalıştırdığımda ne yapacağına dair kesin bir fikrim yok.

Seçtiğim başka bir nedeni /opt, genellikle /opt/'package'dizinin dışındaki herhangi bir dosyaya (ve diğer optdizinlere /etc/opt) güvenmeyen üçüncü taraf, bağımsız kodlar içindir .

Hiçbir koşulda / opt, / var / opt ve / etc / opt hiyerarşilerinin dışında, düzgün çalışması için dosya sistemi ağacındaki belirli konumlarda bulunması gereken paketler dışında başka paket dosyaları bulunmaz. [...] Genel olarak, bir sistemde bir paketi desteklemek için gereken tüm veriler, / etc / opt / 'package' ve / var / opt / 'içine kopyalanması amaçlanan dosyalar dahil / opt /' package 'içinde bulunmalıdır. paket 'in yanı sıra / opt.

Kaynak kodunu serbest bırakmanın bir avantajı, insanların derleme işlemini yapılandırarak sistem özelliklerine göre özel kütüphane / başlık yolları sağlamasıdır. Bir geliştirici kodu çalıştırılabilir olarak yayınlamaya karar verdiğinde, bu avantaj kaybedilir. IMHO, bu noktada, geliştiricinin artık programının bağımlılıklarının kullanılabilir olacağını varsaymasına izin verilmemektedir (bu yüzden her şeyin yürütülebilir dosya ile birlikte paketlenmesi gerekir).

Buraya yüklenecek herhangi bir paket statik dosyalarını (örneğin, ekstra yazı tipleri, küçük resim, veritabanı dosyaları) ayrı bir / opt / 'package' veya / opt / 'sağlayıcı' dizin ağacında (Windows'un kurulum yoluna benzer) bulmalıdır kendi dizin ağacına yeni yazılım C: \ Windows \ Progam Files \ "Program Adı"), burada 'paket' yazılım paketini tanımlayan bir isim ve 'sağlayıcı' sağlayıcının LANANA kayıtlı adıdır.

Daha fazla bilgi için, ben de okuma öneririz bu diğer U & L sorusunu , betwen farklılıkları fırsatlar /optve /usr/local. Ben şahsen önleyeceğini /usr/localo ben değilim, özellikle bu durumda inşa ben yüklüyorum programı.

Visual Studio Code örneğinizde olduğu gibi bir ikili zip arşivinden veya tarball'dan bir dağıtım ikili paketi oluşturmak tamamen mümkündür ve aslında oldukça kolaydır.

Evet, debs ve rpms gibi Linux dağıtım ikili paketleri genellikle kaynaktan üretilir, ancak olmaları gerekmez. Ve her zaman olmasa da, sonuçta ortaya çıkan dağıtım ikili paketinin dağıtım politikasına uymak için "doğru" yerlere bir şeyler yükleyeceği şeyleri düzenlemek her zaman mümkündür.

Rastgele tescilli bir tarball durumunda, yazılımı düzgün bir şekilde kurmanın bir yolu varsa, örneğin bir markaya bir kurulum hedefi varsa, o zaman dağıtım paketleme makineleri ile kullanılabilir. Aksi takdirde, bu, dosyaları "doğru" yerlere "elle" eşleştirmeyi içerebilir ve bu da çok fazla iş olabilir. Böyle bir paket oluşturmak garip bir şey gibi görünse de, paket yönetiminin en önemli avantajlarından birine, yani temiz yükleme ve kaldırma işlemlerine sahip olacaktı. Ve elbette böyle bir paket asla isme değecek herhangi bir Linux dağıtımına kabul edilmeyecektir, ancak bu sizin sorunuz değil.

İkili bir çalıştırılabilir ve başka bir şey olarak teslim edilen yazılımı nadiren gördüm ve açıkçası bundan biraz şüpheliyim. Başka bir şey değilse en azından bir README(yükleme talimatları ile) ve bir LICENSEeşlik etmesini beklenir . Söyleniyor ki...

Distro'nun paket yöneticisi tarafından yönetilmeyen yerel olarak kurulu ikili dosyaların tutulduğu olağan yer /usr/local/bin. Oraya koyabilirsiniz ve bu dizin zaten sizin $PATHiçinizde olduğundan (veya olması gerektiğinden) , komut satırına adını yazarak yazılımı çalıştırabilirsiniz.

Genellikle Yazılım ayrıca gider bir manpage (belgesiz yazılım doğru, kötü?) Sahip olmalıdır /usr/local/manve bu tür içinde gidebilir diğer diller ve eklentileri içine çevirileri gibi bazı destek dosyaları olabilir /usr/local/shareveya /usr/local/lib, vb. Bu nedenle, paket olarak teslim edilmeyen .debveya .rpmgenellikle her şeyi doğru yerlere yerleştiren bir yükleyici ile birlikte gelen yazılımlar. Kaynaktan kurulum yaparken, bu genellikle make install.