Jak zainstalować pliki wykonywalne

Czasami spotykam się z oprogramowaniem, które nie jest oferowane w .deblub .rpmtylko jako plik wykonywalny.
Na przykład Visual Studio Code , WebStorm lub Kerbal Space Programm .

W przypadku tego pytania wezmę Visual Studio Code za punkt odniesienia.

Oprogramowanie jest oferowane jako pakiet zip.
Podczas rozpakowywania pozostaje mi folder o nazwie VSCode-linux-x64zawierający plik wykonywalny o nazwie Code.
Mogę dwukrotnie kliknąć Codelub wskazać na terminalu, /home/user/Downloads/VSCode-linux-x64/Codeaby go wykonać.
Chciałbym jednak wiedzieć, czy istnieje właściwy sposób zainstalowania tych aplikacji.

Chcę osiągnąć:

• jedno miejsce, w którym mogę umieścić wszystkie aplikacje / oprogramowanie oferowane w ten sposób (pliki wykonywalne)
• obsługa terminali (to znaczy na przykład: mogę pisać vscodez dowolnego folderu w moim terminalu, a to automatycznie wykona Visual Studio Code.

Dodatkowe informacje:

• Środowisko pulpitu: Gnome3
• System operacyjny: Debian

EDYCJA:
Postanowiłem udzielić odpowiedzi @kba, ponieważ jego podejście działa lepiej z moim rozwiązaniem do tworzenia kopii zapasowych, a poza tym. Posiadanie skryptu wykonującego pliki binarne daje możliwość dodawania argumentów.
Ale żeby być uczciwym, podejście Johna WH Smitha jest tak samo dobre jak @ kba.

Aby wywołać program po nazwie, powłoki przeszukują katalogi w $PATHzmiennej środowiskowej. W Debianie domyślna wartość $PATHdla twojego użytkownika powinna obejmować /home/YOUR-USER-NAME/bin(tj ~/bin.).

Najpierw upewnij się, że katalog ~/binistnieje lub utwórz go, jeśli nie:

mkdir -p ~/bin

Możesz dowiązać pliki binarne do tego katalogu, aby udostępnić go powłoce:

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

Umożliwi to uruchamianie vscodew wierszu polecenia lub z poziomu programu uruchamiającego polecenia.

Uwaga: Możesz również kopiować pliki binarne do $PATHkatalogów, ale może to powodować problemy, jeśli zależą one od ścieżek względnych.

Zasadniczo jednak zawsze lepiej jest poprawnie zainstalować oprogramowanie przy użyciu środków dostarczonych przez system operacyjny (apt-get, pakiety deb) lub narzędzi do budowania projektu oprogramowania. Zapewni to prawidłowe skonfigurowanie ścieżek zależnych (takich jak skrypty startowe, strony podręcznika man, konfiguracje itp.).

Aktualizacja: Odzwierciedla także komentarze Thomasa Dickeya i odpowiedź Faheema Mithy na to, co zwykle robię dla oprogramowania, które jest dostarczane jako tarball z plikiem binarnym najwyższego poziomu i oczekuje się, że będzie z niego uruchamiany:

Umieścić go w miejscu sane (w kolejności według standardów zgodności /opt, /usr/locallub folder w katalogu domowym, na przykład ~/build) i utworzyć wykonywalny skrypt otoki w $PATHmiejscu (na przykład /usr/local/binlub ~/bin), że zmiany w tym miejscu i wykonuje binarne:

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

Ponieważ emuluje to przejście do tego katalogu i ręczne wykonanie pliku binarnego, ułatwia debugowanie problemów, takich jak nieistniejące ścieżki względne.

Według tldp , /optmoże być dobrym miejscem dla tego rodzaju oprogramowania. Użyłem go sam do przechowywania niektórych narzędzi związanych z drukarką, a „dynamiczną” wersję Skype'a (jak powiedział kba, „obsługę terminali” można wówczas uzyskać poprzez odpowiednie ustawienie PATHzmiennej).

Mówiąc bardziej ogólnie, zwykle używam /optdo „instalowania” oprogramowania zastrzeżonego spakowanego jako plik wykonywalny, ale to chyba tylko ja. Poza tym staram się po prostu unikać tego rodzaju oprogramowania, ponieważ zwykle nie mam pewności, co on zrobi po uruchomieniu.

Innym powodem, dla którego wybrałem /optjest to, że zwykle jest przeznaczony do niezależnego kodu innej firmy, który nie opiera się na żadnym pliku poza jego /opt/'package'katalogiem (i innymi optkatalogami, takimi jak /etc/opt).

W żadnym wypadku inne pliki pakietów nie mogą istnieć poza hierarchiami / opt, / var / opt i / etc / opt, z wyjątkiem plików pakietów, które muszą znajdować się w określonych lokalizacjach w drzewie systemu plików, aby poprawnie funkcjonować. [...] Zasadniczo wszystkie dane wymagane do obsługi pakietu w systemie muszą znajdować się w katalogu / opt / „package”, w tym pliki przeznaczone do skopiowania do / etc / opt / „package” i / var / opt / ” pakiet ”oraz zastrzeżone katalogi w / opt.

Jedną z zalet wydania kodu źródłowego jest to, że ludzie mogą skonfigurować proces kompilacji, zapewniając niestandardowe ścieżki biblioteki / nagłówków w oparciu o specyfikę ich systemu. Gdy programista decyduje się wydać kod jako plik wykonywalny, ta korzyść zostaje utracona. IMHO, w tym momencie, deweloper nie może już zakładać, że zależności jego / jej programu będą dostępne (dlatego wszystko powinno być spakowane obok pliku wykonywalnego).

Każdy pakiet do zainstalowania w tym miejscu musi zlokalizować swoje pliki statyczne (tj. Dodatkowe czcionki, clipart, pliki bazy danych) w osobnym drzewie katalogów / opt / „package” lub / opt / „provider” (podobnie do sposobu instalacji systemu Windows nowe oprogramowanie do własnego drzewa katalogów C: \ Windows \ Progam Files \ „Nazwa programu”), gdzie „pakiet” to nazwa opisująca pakiet oprogramowania, a „dostawca” to zarejestrowana nazwa dostawcy LANANA.

Aby uzyskać więcej informacji, sugerowałbym również przeczytanie tego innego pytania dotyczącego U&L , które dotyczy różnic między /opti /usr/local. Osobiście unikałbym /usr/localw tym przypadku, zwłaszcza jeśli nie jestem tym, który zbudował program, który instaluję.

Jest całkowicie możliwe, a właściwie całkiem łatwe, utworzenie binarnego pakietu dystrybucyjnego z binarnego archiwum zip lub tarballa, jak w twoim przykładzie Visual Studio Code.

Tak, pakiety binarne dystrybucji Linuksa, takie jak debsi i rpms, są zwyczajowo generowane ze źródła, ale nie muszą tak być. I często (choć nie zawsze) możliwe jest takie ustawienie, aby wynikowy pakiet binarny dystrybucji instalował rzeczy w „odpowiednich” miejscach, aby zachować zgodność z polityką dystrybucji.

W przypadku losowego, zastrzeżonego pliku tar, jeśli istnieje sposób na prawidłową instalację oprogramowania, np. Cel instalacji w pliku makefile, wówczas można go użyć z maszyną do dystrybucji. W przeciwnym razie może to wymagać „ręcznego” mapowania plików do „właściwych” miejsc, co może być bardzo pracochłonne. Tworzenie takiego pakietu może wydawać się dziwną rzeczą, ale nadal miałoby jedną z głównych zalet zarządzania pakietami, a mianowicie czyste instalacje i odinstalowywanie. I oczywiście taki pakiet nigdy nie zostanie zaakceptowany w żadnej dystrybucji Linuksa wartej nazwy, ale to nie jest twoje pytanie.

Rzadko widziałem oprogramowanie dostarczane jako binarny plik wykonywalny i nic więcej, i szczerze mówiąc, byłbym trochę podejrzliwy. Jeśli nic innego nie spodziewałbym się przynajmniej README(wraz z instrukcją instalacji) i LICENSEtowarzyszącego mu. Biorąc to pod uwagę ...

Zwykle przechowywane są lokalnie zainstalowane pliki binarne, którymi nie zarządza menedżer pakietów dystrybucji /usr/local/bin. Możesz go tam umieścić, a ponieważ ten katalog jest (lub powinien być) już w twoim $PATH, możesz uruchomić oprogramowanie, wpisując jego nazwę w wierszu poleceń.

Zwykle oprogramowanie powinno również zawierać stronę podręczną (oprogramowanie nieudokumentowane jest złe, prawda?), Która się pojawia /usr/local/mani może zawierać pliki pomocnicze, takie jak tłumaczenia na inne języki i wtyczki, które mogą się pojawiać /usr/local/sharelub /usr/local/libitd. Z tego powodu oprogramowanie, które nie jest dostarczane jako pakiet, takie jak .deblub .rpmzazwyczaj, zawiera instalator, który umieszcza wszystko we właściwych miejscach. Zwykle jest to instalowane ze źródła make install.