Как установить исполняемые файлы

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

По этому вопросу я возьму код Visual Studio как точку отсчета.

Программное обеспечение предлагается в виде застежки-молнии.
При распаковке у меня остается папка с именем VSCode-linux-x64 которая содержит исполняемый файл с именем Code .
Я могу дважды щелкнуть Code или указать на него своим терминалом, например /home/user/Downloads/VSCode-linux-x64/Code чтобы выполнить его.
Однако я хотел бы знать, есть ли способ установки этих приложений.

Я хочу достичь:

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

Дополнительная информация:

  • Рабочий стол: Gnome3
  • ОС: Debian

РЕДАКТИРОВАТЬ:
Я решил дать @kba ответ, потому что его подход работает лучше с моим резервным решением и, кроме того. Наличие скрипта, исполняющего двоичные файлы, дает вам возможность добавлять аргументы.
Но, честно говоря, подход @John WH Smith так же хорош, как и @ kba.

4 Solutions collect form web for “Как установить исполняемые файлы”

Чтобы вызвать программу по ее имени, оболочки просматривают каталоги в $PATH среды $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 packages) или инструменты сборки программного проекта. Это обеспечит правильную настройку зависимых путей (например, стартовых скриптов, man-страниц, конфигураций и т. Д.).

Обновление: также отражая комментарии Томаса Дики и ответы Faheem Mitha, что я обычно делаю для программного обеспечения, которое поставляется в виде tarball с бинарным кодом верхнего уровня и ожидает оттуда:

Поместите его в правильное место (в порядке соответствия стандартам /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.

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

Любой пакет, который должен быть установлен здесь, должен найти свои статические файлы (например, дополнительные шрифты, клипарт, файлы базы данных) в отдельном дереве каталогов / opt / 'package' или / opt / 'provider' (аналогично тому, как Windows будет устанавливать новое программное обеспечение в свое собственное дерево каталогов. C: \ Windows \ Progam Files \ «Название программы»), где «package» – это имя, которое описывает пакет программного обеспечения, а «поставщик» – это зарегистрированное имя LANANA провайдера.

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

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

Да, бинарные пакеты дистрибутива Linux, такие как deb s и rpm s, обычно генерируются из источника, но они не обязательно должны быть. И часто (хотя и не всегда) можно организовать вещи, чтобы полученный бинарный пакет распределения устанавливал вещи в «правильных» местах, чтобы соответствовать политике распространения.

В случае случайного запатентованного tarball, если бы был способ правильно установить программное обеспечение, например, установить цель в make-файле, то это можно было бы использовать с оборудованием для распределения упаковки. В противном случае это может включать «вручную» файлы сопоставления в «правильные» места, что может быть очень большой работой. Хотя создание такого пакета может показаться странным, он все равно будет иметь одно из основных преимуществ управления пакетами, а именно: чистая установка и удаление. И, конечно, такой пакет никогда не будет принят в дистрибутив Linux, но это не ваш вопрос.

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

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

Обычно у программного обеспечения также должна быть manpage (недокументированное программное обеспечение плохое, верно?), Которое входит в /usr/local/man и может иметь некоторые файлы поддержки, такие как переводы на другие языки и плагины, которые могут находиться в /usr/local/share или /usr/local/lib и т. д. По этой причине программное обеспечение, которое не поставляется в виде пакета, такого как .deb или .rpm обычно поставляется с установщиком, который помещает все в нужные места. Когда вы устанавливаете источник, это обычно make install .

Interesting Posts
Linux и Unix - лучшая ОС в мире.