Як встановити виконувані файли

Іноді я стикаюся з програмним забезпеченням, яке не пропонується .debабо є .rpmлише виконуваним.
Наприклад, Visual Studio Code , WebStorm або Kerbal Space Programm .

Для цього питання я візьму Visual Studio Code як точку відліку.

Програмне забезпечення пропонується у вигляді пакету на блискавці.
Під час розпакування мені залишається папка під назвою, VSCode-linux-x64яка містить виконувану назву Code.
Я можу двічі клацнути Codeабо вказати на нього своїм терміналом, як би /home/user/Downloads/VSCode-linux-x64/Codeйого виконати.
Однак я хотів би знати, чи є правильний спосіб встановлення цих додатків.

Я хочу досягти:

• одне місце, де я можу розмістити всі програми / програмні засоби, які пропонуються таким чином (виконувані файли)
• підтримка терміналу (це означає, наприклад: я можу писати vscodeз будь-якої папки свого терміналу, і він автоматично виконає код Visual Studio.

Додаткова інформація:

• Настольне середовище: Gnome3
• ОС: Debian

EDIT:
Я вирішив дати відповідь @kba, оскільки його підхід краще працює з моїм резервним рішенням, і крім цього. Виконання сценарію бінарних файлів дає можливість додавати аргументи.
Але якщо бути справедливим, @John WH Сміт підхід настільки ж хороший, як і @ kba.

Щоб викликати програму за її назвою, оболонки шукають каталоги в $PATHзмінній середовища. У Debian за замовчуванням $PATHдля вашого користувача повинен міститись /home/YOUR-USER-NAME/bin(тобто ~/bin).

Спочатку переконайтеся, що каталог ~/binіснує або створити його, якщо він не виконаний:

mkdir -p ~/bin

Ви можете позначити бінарні файли до цього каталогу, щоб зробити його доступним для оболонки:

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

Це дозволить вам запуститись vscodeу командному рядку або із запуску команд.

Примітка: Ви також можете скопіювати бінарні файли в $PATHкаталоги, але це може спричинити проблеми, якщо вони залежать від відносних шляхів.

Однак, як правило, завжди бажано правильно встановити програмне забезпечення за допомогою засобів, передбачених ОС (apt-get, deb-пакети) або інструментами побудови програмного проекту. Це забезпечить правильне налаштування залежних шляхів (наприклад, сценарії запуску, керівні сторінки, конфігурації тощо).

Оновлення: також відображаючи коментарі Томаса Дікі та відповідь Фахіма Мітхи, що я зазвичай роблю для програмного забезпечення, яке поставляється у вигляді тарболу з бінарним верхнім рівнем і очікується, що його запустити звідти:

Покладіть його в місці осудної (в порядку стандартів відповідності /opt, /usr/localабо папку в вашому домашньому каталозі, наприклад ~/build) і створити виконуваний скрипт - обгортку в $PATHмісці (наприклад , /usr/local/binчи ~/bin) , що зміни в це місце і виконують двоичное:

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

Оскільки це емуляція зміни до цього каталогу та виконання бінарного файлу вручну, це спрощує налагодження проблем, як неіснуючі відносні шляхи.

На думку TLDP , це /optможе бути хорошим місцем для такого типу програмного забезпечення. Я сам використовував це для зберігання деяких інструментів, пов’язаних із принтером, і "динамічну" версію Skype (як сказав kba, "підтримка терміналу" може бути досягнута відповідно встановленням PATHзмінної).

Більш загально, я, як правило, використовую /optдля "встановлення" власного програмного забезпечення, упакованого як виконуваний файл, але це, мабуть, тільки я. Крім того, я, як правило, просто уникаю подібного програмного забезпечення, оскільки зазвичай не знаю, що робити, як тільки його запускати.

Ще одна причина, чому я вибрав /optце, тому що він зазвичай призначений для стороннього незалежного коду, який не покладається на жоден файл поза його /opt/'package'каталогом (та інші optкаталоги, такі як /etc/opt).

Ні за яких обставин не існують інші файли пакетів за межами ієрархій / opt, / var / opt та / etc / opt, за винятком тих файлів пакетів, які повинні нормально функціонувати в дереві файлової системи. [...] Як правило, всі дані, необхідні для підтримки пакету в системі, повинні бути присутніми в / opt / 'package', включаючи файли, призначені для копіювання в / etc / opt / 'package' та / var / opt / ' пакет ", а також зарезервовані каталоги в / opt.

Однією з переваг випуску вихідного коду є те, що люди отримують можливість налаштувати процес компіляції, надаючи власні шляхи до бібліотеки / заголовків на основі специфіки їх системи. Коли розробник вирішує випустити код як виконуваний файл, ця перевага втрачається. ІМХО, на даний момент розробнику більше не дозволяється припускати, що залежності від його програми будуть доступні (саме тому все повинно бути упаковано поряд із виконуваним файлом).

Будь-який пакет для встановлення тут повинен знаходити статичні файли (тобто додаткові шрифти, кліпарт, файли баз даних) в окремому дереві каталогів / opt / 'package' або / opt / 'provider' (подібний до способу встановлення Windows нове програмне забезпечення для власного дерева каталогів C: \ Windows \ Progam Files \ "Назва програми"), де "пакунок" - це ім'я, яке описує пакет програмного забезпечення, а "постачальник" - зареєстроване ім'я LANANA провайдера.

Для отримання додаткової інформації я б також запропонував прочитати це інше питання щодо U&L , яке стосується відмінностей між /optта /usr/local. Я б особисто уникав /usr/localцього випадку, особливо якщо я не той, хто будував програму, яку я встановлюю.

Цілком можливо, а насправді досить просто створити розподільний двійковий пакет з бінарного zip-архіву чи тарболу, як у вашому прикладі Visual Studio Code.

Так, бінарні пакети дистрибуції Linux, такі як debs і rpms, зазвичай генеруються з джерела, але вони не повинні бути. І часто (хоча і не завжди) можливо влаштовувати речі так, щоб отриманий у розпорядженні двійковий пакет розподілу встановлював речі у «правильних» місцях, щоб відповідати політиці розподілу.

У випадку випадкового фірмового тарболу, якщо існував спосіб належної установки програмного забезпечення, наприклад, цілі встановлення в makefile, то це може бути використане з машинами для роздачі пакування. В іншому випадку це може включати "вручну" зіставлення файлів у "правильні" місця, що може бути багато роботи. Хоча створення такого пакету може здатися дивним, це все одно матиме одну з головних переваг управління пакунками, а саме чисті встановлення та видалення. І звичайно, такий пакет ніколи не буде прийнятий до жодного дистрибутива Linux, який вартує назви, але це не ваше питання.

Я рідко бачив програмне забезпечення, яке постачається просто як двійковий виконуваний файл, і нічого іншого, і я відверто кажучи, трохи підозрілий у цьому. Якщо б нічого іншого, я, принаймні, очікував README(із інструкціями щодо його встановлення) та LICENSEсупровід. Це сумно...

Звичайним місцем зберігання локально встановлених бінарних файлів, якими не керує диспетчер пакунків дистрибутива, є /usr/local/bin. Ви можете розмістити його там, і оскільки цей каталог вже є (або повинен бути) у вашому, $PATHви можете запустити програмне забезпечення, ввівши його ім'я в командному рядку.

Зазвичай це програмне забезпечення має також мати сторінку (незадокументоване програмне забезпечення погано, правда?), Яка входить /usr/local/manі може мати деякі файли підтримки, такі як переклади на інші мови та плагіни, які можуть увійти /usr/local/shareабо /usr/local/libтак далі. З цієї причини програмне забезпечення, яке не постачається у вигляді пакету, наприклад, .debабо, .rpmяк правило, постачається з інсталятором, який розміщує все в потрібних місцях. Коли ви встановлюєте з джерела, це зазвичай make install.